Table of Contents
Advertisement
How Secure Updates Work
When a dynamic update is made to a secure MS-DNS server, the security verification
happens in (very simplistically) two stages. First the GSS-TSIG protocol is used to verify
the identity of the sender as well as the receiver and validate that the contents of the up-
date have not been tampered with. This stage uses Kerberos as the underlying security
provider. Second, the DNS server takes the update and uses the updater's security con-
text to update Active Directory with the new information. At this stage Active Directory's
security mechanism is invoked.
Access Control Information
Active Directory keeps access control information with each entry in AD. This access
control information specifies who owns the entry and who is allowed to access it. For
example, an entry can be owned by UserA and allow all authenticated users to read the
information but only allow administrators and UserA to modify the information.
If the access control information does not forbid the updater from making changes to the
Active Directory entry it is trying to modify, the update succeeds. At this stage, if the en-
try had no security or did not previously exist, the access control information for the entry
is updated such that only the updater (and administrators) are allowed to make changes
to the entry.
There is one exception to this rule: when the updater is a member of a special security
group called DNSUpdateProxy. Objects created by members of the DNSUpdateProxy
group have no security; therefore, any authenticated user can take ownership of the
objects.
Use of Secure Zones in Solution 2
Secure zones offer a higher level of security than an allow-update ACL list does, since
the spoofing of IP addresses cannot circumvent it. It is much more complicated to
implement and manage, however, especially if platforms other than Windows 2003 are
involved. For Solution 2, we have made the assumption that GSS-TSIG is already work-
ing fine for your MS-DNS servers. Therefore, the only change needed to have VitalQIP
6.1 SP1 manage these servers is setting up the GSS-TSIG information to allow DNS
Generation of secure zones to MS-DNS, which would always be performed for changed
records only. (VitalQIP 6.2 is able to send secure DDNS updates to Microsoft DNS as
well as DNS Generation, but this capability does not exist in VitalQIP 6.1 SP1.)
Management of Windows 2003 Secure Zones by VitalQIP
VitalQIP does not attempt to store the access control information for each DNS record.
Therefore, the clients associated with these records do not own the records created
by DNS Generation from VitalQIP. Instead, records created by VitalQIP have one of
two owners: either the Strong Kerberos Principal, or the Proxy Kerberos Principal. The
Strong Kerberos Principal is associated with the DNS administrators group in AD; this
account has permissions to override other updates. VitalQIP uses this account to cre-
ate the records for Static IP objects, so that only VitalQIP can update them. The Proxy
account is used for creation of External or Partially Managed Objects. This allows the
clients themselves or the MS-DHCP server to take over ownership of these records, and
be able to update the records as changes occur. Dynamic objects can be generated with
either the Strong Kerberos Principal or the Proxy Kerberos Principal, depending on the
value of the Allow DHCP Clients to Modify Dynamic Object Resource Records policy. If
this is set to True, the records are associated with the Proxy account and can be taken
21
Alcatel-Lucent | Integration of VitalQIP® with Microsoft Windows 2003 Networking/Active Directory
Advertisement
Table of Contents
