Monthly Archives: November 2012

Azure AD, Microsoft Azure

Which accounts can I assign as Windows Azure co-administrators?

Leave a comment

Recently the ability to add co-administrators to you Windows Azure portal was migrated from the old Silverlight portal to the new HTML 5 portal. Happy times!

You can only add valid Microsoft Accounts or accounts from Windows Azure Active Directory as co-administrators. Office 365 uses Windows Azure Active Directory to if you have an account there it can be assigned as a co-administrators. If you enter an invald account the portal will inform you:

image

Security

Decoding some certificate enrollment client events

Leave a comment

The Events

Windows clients can request certificates on their own (autoenrollment) or with the help of a user. When enrolling for a certificate you may find this pair of events in your Application log:

Source: Microsoft-Windows-CertificateServicesClient-CertEnroll
Event ID: 64
Level: Information
User: S-1-5-18
User Name: NT AUTHORITYSYSTEM
Computer: <servername>
Description: Certificate enrollment for Local system successfully load policy from policy server

Source: Microsoft-Windows-CertificateServicesClient-CertEnroll
Event ID: 65
Level: Information
User: S-1-5-18
User Name: NT AUTHORITYSYSTEM
Computer: <servername>
Description: Certificate enrollment for Local system is successfully authenticated by policy server {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}

Obviously the local system successfully enrolled for a certificate, but what do these actually tell us?

Decoding

Let’s start with the first event with if 65 (remember, the newest events are at the top of the event log). It tells us that a CA, included in a certificate enrollment policy, identified by GUID, has successfully authenticated the system’s enrollment request. In the Windows help we find this about certificate enrollment policies:

Certificate enrollment policy provides the locations of certification authorities (CAs) and the types of certificates that can be requested. Organizations that are using Active Directory Domain Services (AD DS) can use Group Policy to provide certificate enrollment policy to domain members by using the Group Policy Management Console to configure the certificate enrollment policy settings. The Certificates snap-in can be used to configure certificate enrollment policy settings for individual client computers unless the Group Policy setting is configured to disable user-configured enrollment policy.

Unless you have added some yourself, there is one default certificate enrollment policy, the Active Directory Enrollment Policy.

To display the enrollment policies you can run certutil.exe –Policy. It will give you a list of your enrollment policies:

Name: Active Directory Enrollment Policy
Id: {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}
Url: ldap:
NextUpdate: EMPTY
LastUpdate: EMPTY
Url Flags = 15 (21)
PsfLocationGroupPolicy — 1
PsfAutoEnrollmentEnabled — 10 (16)
0x4 (4)
Authentication = 2
Kerberos — 2
AllowUntrustedCA: 0
Priority: 7ffffffd (2147483645)
CertUtil: -Policy command completed successfully.

If you look back at the events at the beginning of this post you will recognize the GUID in the event with ID 65. The GUID in the event is the Enrollment Policy ID. So that event is saying that the system was successfully authenticated against the Active Directory Enrollment Policy. Here is a screenshot of the policy as well:

image

NOTE: If you want to see the defalt certificate enrollment policy and create new ones you need to use Group Policy. You can also create new certificate enrollment policies using the Certificates MMC. See the links below:

Now, if you want to see which CAs are in that enrollment policy you can run certutil.exe –CA (my output is concatenated):

Name: Active Directory Enrollment Policy
Id: {AFD04357-74D7-47B3-82BC-BBE76F4E6F3D}
Url: ldap:
6 CAs:

CA[0]:
CAPropCommonName = <CA Name>
CAPropDNSName = <CA Server FQDN>
CAPropCertificateTypes =
0: EFSRecovery
1: EFS
2: DomainController
3: WebServer
4: Machine
5: User
6: SubCA
7: Administrator

CAPropSecurity = <SDDL>

Without the Certificate Enrollment Policy Web Service role service installed, the only way to get certificate policy information from Active Directory is by using LDAP. This can obviously be a problem so the Certificate Enrollment Policy Web Service role service was created to allow certificate policy information to be retreived over HTTPS also. The Web Service functions as a proxy; accepting client requests for policy over HTTPS and querying Active Directory for certificate policy information over LDAP.

So now we know what the first event (ID 65) means.

The next event is much easier; it just says that the system was able to load the certificate enrollment policy successfully from the CA.

More information:

Active Directory

Enabling notify-driven replication across Active Directory sites

1 Comment

Introduction

Active Directory sites, site links and site link bridges exist to be able to tell the directory service about the network’s physical topology. Specifically to identiy which parts of it are well connected and where there are slow WAN links. The rule of thumb here is that all systems that are connected with at backbone of 10 Mbps or more are considered well connected. These should therefore be contained in a site. Two or more sites of well connected systems can be linked with site links that have a schedule and an associated cost. The cost can be said to represent how fast the link is. Low cost would cause the directory to prefer it while a high cost would be more prohibitive. The way we identify systems in Active Directory is by either IPv4 or IPv6 subnets. A list of IP subnets define a site. Needless to say; the exact same IP subnet cannot be associated with more than one site within the same forest.

However, this functionality also has another application. It can be used to created advanced replicaton topologies that segment your Active Directory.

Segmentation of Active Directory

Whenever you need to control the communication paths between domain controllers you need sites and site links. In these situations, network speed is not the issue, but rather where communication is allowed. The default topology of Active Directory replication within a site is a least-cost spanning tree. If there are any firwall or blocked communication paths between any DCs the directory cannot know about this without defined sites and site links. If you use only one site in such a situation you will not have a functional replication topology.

Let’s say you have a network comprising of two zones with different security levels (Figure 1). Typically these two zones would be segmented by a firewall. However, to make administration and user experience easier and better you want to use the same domain across the zones. If you have 4 DCs in each zone, for a total of 8 DCs in the domain you would have to allow communication from all DCs in one zone to all DCs in the other zone and vice versa if you had only one site. With two sites, one for each security level/zone, with one or two bridgehead servers defined in each site, you would have much fewer openings in your firewall.

Figure 1

This is also very useful for Active Directory aware clients and services who try to use the DCs closest to them. Returning to our example of a network with two zones and a firewall separating them, clients in one zone would not be allowed to access DCs in the other. Clients from a zone with a lower security level typically cannot access resources in higher security levels. Depending on the circumstances the reverse may also be true. Clients from a higher security level cannot access resources on a lower level. With only one site spanning the two zones clients in either zone has a 50 % chance of trying to contact a DC they cannot communicate with (if there is an equal number of DCs in each zone). This is because they think that any DC in the site is available. On the other hand with a correctly defined site topology where the correct IP subnets are associated with the correct site, clients will not attempt to communicate with a DC in another site unless all the DCs in their own site are down.

But there is one challenge with this approach, and that is the speed of replication between sites. In our scenario network speed is not an issue. These configrations are typically segmented LANs with high speed backbones and firewalls. However, Active Directory regards sites as well connected and the links between sites as much slower. Therefore site links only replicate on a schedule, not by using notifications as DCs do within a site. The lowest replication interval you can set on a site link is 15 minutes, meaning that Active Directory updates are replicated across the site link every 15 minutes.

Within a site replication is notificaton-driven. A DC with an originating (a write that is done on the local DC) or replicated (a write done on the local DC but as the result of replication of an update from another DC) update will send a notification message to all its intra site replication partners that it has changes that need to be replicated. The DCs receiving these messages will in turn connect to the originating DC and pull the changes and update their own copies of the database. All Active Directory replication is pull-based meaning that a DC will never push its changes over to any other DC. It will just notify them and they initiate a pull to replicate any changes. This is also true for inter site replication, except between sites there are no notifications, but a schedule and a replication interval (Figure 2).

Figure 2

Each time the interval is reached the DCs will initiate pull replication with their configured parteners across the site links. This works this way because site links are thought to be slow and costly. Thus Active Directory does not want to monopolize them with a lot of singe obejct updates, but rather replicate a lot of objects in a queue at specific intervals. It is this behaviour we want to modify to make Active Directory updates as speedy between sites as they are within sites. Remember, in our scenario network speed is not an issue, we just want to segment our domain.

Configuring site links to use notification based replication

Whether to use notification or a replication interval to replicate across a site link is configured pr. site link. If all your sites are in the same site link configuration is simple, but if you have several sites links, in a hub-spoke topology e.g., you will have to configure each site link.

In this example we will configure the DEFAULTIPSITELINK site link that is created automatically in every Active Directory forest and contains all sites by default.

You can make the change using any tool able to write to Active Directory attributes.  I will use Active Directory Sites and Services since that is the easiest way. The change itself requires Enterpise Admin level permissions.

  1. Find the site link you want to change, right click and select Properties.
  2. Select the Attributes Editor tab.
  3. Find the options attribute (make sure that you display all attributes regardless of whether they have a value or not, since this attribute does not have a value by default).
  4. Set the value of the options attribute to 1. Notice how you will now have an explanation behind the 1 value indicating that you have configured the link to use notifications (USE_NOTIFY).
  5. Replicate this change to all DC manually or wait for regular scheduled Active Directory replication.

image

The options attribute uses a bitmap. Its possible values are:

Decimal Value Binary Value Explanation
1 1 USE_NOTIFY
2 10 TWOWAY_SYNC
4 100 DISABLE_COMPRESSION

You can use any combination of these. If your options attribute already has a value you need to perform a BITWISE OR operation on the existing value. If the value is 4, convert that to binary (100), perform an OR operation with binary 1, the result should be binary 101, which you convert to decimal (5) and enter as the value of the options attribute.

More information