Jay Paloma's Tech and Music Blog

Sometimes, this writer can no longer distinguish between the two.

Archive for the ‘Active Directory’ Category

Presenting, The Top 10 Posts for 2012!!!

leave a comment »

Here they are … drum roll please!

  1. Active Directory Organizational Unit Design Principles
  2. Active Directory Forest Design Principles
  3. Workaround: Outlook rules don’t run on additional MAPI mailboxes
  4. Active Directory Site and Replication Design Principles
  5. Active Directory Group Policy Design Principles
  6. Active Directory Domain Design Principles
  7. Using WMI to Filter GPO’s based on Windows Version and Role
  8. Hyper-V Virtualization Stencils for Visio 2010
  9. My Top Gun Anthem Story: Using Backing Tracks in a Live Performance
  10. MDT 2010 Update 1 – Part 1 of 3 – What is User Driven Installation?

Category summary as follows:

  1. Active Directory = 6
  2. Messaging = 1
  3. Office = 1
  4. Music = 1
  5. Deployment = 1

Thank you very much and Happy New Year to all!

jay paloma  |  31 dec 2012  |  singapore


Written by jpaloma

December 31, 2012 at 9:50 AM

NTLM: When do you still encounter it

leave a comment »

NTLM, or NT LAN Manager, is Microsoft’s authentication protocol during the Windows NT days. With the advent of Active Directory, NTLM is being phased out, therefore 3rd party application developer follow suit. This led me to an encounter a while back where the unexpected presence of NTLM in the authentication mechanism of an organization caused some challenges in a project I am working in. This led me to research in spite of the implementation of Active Directory and using Kerberos as the authentication protocol, when does Windows fall back to NTLM? Because it does!

  1. Windows NT clients and below. These legacy clients use NTLM. Kerberos is supported only on Windows 2000 and above. No ifs and buts about it.
  2. When DNS resolution fails during authentication. If during the authentication process, DNS fails or cannot find a Domain Controller, the client falls back to NTLM and sort of looks for a “Windows NT Domain Controller.” As such, the authentication method will be NTLM.
  3. Windows 2000 Mixed Mode. This domain functionality mode assumes the presence of Windows NT in the network, therefore the probability that authentication will kick back to NTLM is higher especially if the network is in mixed mode due to the actual presence of Windows NT Backup Domain Controllers in the domain. Read this to know more about domain functional levels in Active Directory.
  4. Inter-Forest External Trust Relationships. An External Trust Relationship is a one- or two-way nontransitive trust between two forests, very similar to the Windows 2000 Trust Relationships. This type of trust relationship assumes that one or both sides of the trust still supports NTLM, therefore authentication between two forests with this type of trust relationship uses NTLM. This is the reason why the transitive trust relationship is not possible in an External Trust Relationship because the transitive concept, or even the forest is unheard of in Windows NT. If you intend to use a trust relationship between forests without NTLM, use the Forest Trust.

If you are in the position where your customer demands why is NTLM still supported in the older version of your product but misbehaves in the newer version due to NTLM, just tell them what I call my “cassette tape” analogy: in the same way that cassette players are no longer a staple in today’s home entertainment systems, so should customers accept the fact that newer products may no longer support older technologies, or misbehave when they encounter these older technologies like NTLM.

Written by jpaloma

December 20, 2012 at 9:22 PM

Posted in Active Directory

Active Directory Design Series – repost from 2006

leave a comment »

I was reviewing my Security is a State of Mind entries and I came across the Active Directory Design series I wrote on Jul-Aug 2006. After reading them, I found that for the most part, the design concepts are still appropriate for today’s Active Directory. I reposted them in my new techblog. Here they are!

Hope you find them useful!

Jay Paloma |  19 Jan 2011 | Singapore

Written by jpaloma

January 19, 2011 at 1:03 PM

Posted in Active Directory

Active Directory Site and Replication Design Principles

with 7 comments

This blog entry was written on Aug 2006. Since much of it is still relevant in today’s Windows Server 2008 R2 Active Directory, I took the liberty of reviewing and reposting it in my new techblog. – Jay Paloma

When I first saw what Active Directory was before the launch of Windows 2000, I got hooked on the fact that Active Directory can now locate resources and conduct replication based on IP addresses. This has been a different case in the Windows NT directory services which does not put into consideration the physical aspects of the directory (i.e., networking). Because of this there are times that there has been a need to create new domains in Windows NT to facilitate proper replication. With AD  site topology there’s now a clear delineation between the physical and logical aspects of the directory.

To properly design your Active Directory physical structure, we need to put into consideration the following factors: location of AD services like domain controllers and DNS servers, IP addressing, WAN links between geographical sites, etc.

It is important to note that Active Directory site topology is dependent on the company’s IP addressing scheme. Each site can contain one or more IP subnets, but each subnet can only be declared on a single site.

Some rules of thumb in Site and Replication Topology Design

  • Active Directory site topology maps to the WAN topology of the organization in most cases
  • Create one site per WAN location, if possible.
  • Ensure that each site has a Domain Controller, a Global Catalog Server and a DNS Server. These three roles can coexist in a single domain controller. In short, ensure that client traffic is contained as much as possible to servers within the same site as the clients.
  • Create site links reflecting your WAN links
  • Schedule replication at off-peak hours

The caveat of having more sites is that domain controller replication is slower between sites than for DC’s that belong to a single site. This is because site replication only happens every 15 mins and is governed by the site topology that you design. In comparison, intrasite domain controller replication happens 5 minutes after an attribute change, and this happens on all other domain controllers within the site.

  • Less sites, more replication bandwidth consumption, less time to replicate
  • More sites, less replication bandwidth consumption, more time to replicate

Significance of the Default-First-Site-Name Site

There is a site created by default when you install Active Directory. It’s the Default-First-Site-Name Site. You may be tempted to delete this site object after creating your sites and moving all your domain controller objects to their respective site containers. Don’t! In fact, ensure that you create a connection agreement between this site and your hub site. If, during your IP subnet encoding phase you overlooked a specific subnet that exists, any additional domain controller you install that belongs to that subnet gets added into the Default-First-Site-Name site, and is ensured of directory replication.

AD Sites and VLANs

I cannot go into site topology without discussing the effect of virtual LANs or VLANs in our design. With VLANs, administrators can join computers that interact often with one another in an IP segment regardless of geophysical location. VLANs exist on a higher level than the physical network and has no dependency on it. Although this may sound good from a technology standpoint, a poorly planned VLAN infrastructure means poor Active Directory logon and replication performance. Worse, this will also affect the performance of Microsoft Exchange.

This is an example of how a poorly implemented VLAN network can have detrimental effects not just on Active Directory, but in Exchange Server as well. Company X is an organization with offices in Manila, Cebu, Davao and Subic. The company designed its VLAN so that all servers are in the same IP segment, while client computers are segmented according to geographical location.

VLANs and AD Site Design

In this case, we can create a site for the servers, and one site each for each geographical location for the clients. Unfortunately, this design would have the following results:

  • Replication between domain controllers are intrasite and not bound by schedules or data compression as compared with intersite replication. In addition, domain controller replication partners will assume the replication partnerships automatically as in a single site topology, and will not be governed by the WAN link topology.
  • The Exchange Servers in MANILA and DAVAO may not necessarily use the Domain Controllers and Global Catalog Servers in their respective areas. Given that all servers are in the same AD Site, then all DC/GC’s may service the requirements of all Exchange Servers without preference to any one.
  • Since all Client Active Directory Sites connect to the Server Active Directory Site, then all clients can be serviced by all domain controllers of the organization. This is true for both Windows authentication and Outlook Directory Services Access to a Global Catalog.

Plan your site structure properly. With it comes maximization of bandwidth and minimized latency of AD object updates.

Written by jpaloma

January 19, 2011 at 11:41 AM

Active Directory Group Policy Design Principles

with 3 comments

This blog entry was written on Aug 2006. Since much of it is still relevant in today’s Windows Server 2008 R2 Active Directory, I took the liberty of reviewing and reposting it in my new techblog. – Jay Paloma

Finally we go to Group Policies. Personally, I find this feature one of the more compelling reasons to make the move to Active Directory. Properly designing and implementing it.

Group Policy processing rules of thumb

These are my 5 rules of thumb I tried to remember when I was taking up the Active Directory Implementation and Active Directory Design exams, and in my subsequent Group Policy design exercises.

Rule 1 – Execution Order: L > S > D > OU. Local policies are procesed first. Then follows the Site GPO’s, then Domain GPO’s, then OU GPO’s from top level OU until the direct container of the user or computer object. Any conflicting settings and the last processed GPO will prevail.

Rule 2 – Inheritance. GPO setings are inherited from the top level containers containers to the direct container of the user or computer object. If we need to remove the Run Menu from all users in our domain, we simply need to create the GPO for this and link it to our domain, instead of linking it on all OU’s where there are user accounts. There are of course, exceptions to the rule.

Rule 3 – Block Inheritance. Block Inheritance is applied to the container and ensures that any policy in the upper level containers are not applied to the container that it is applied to and the downstream containers. This is intended as an exception to Rule # 2 on Inheritance. The proper application to this is a downstream container.

Rule 4 – Link Enforced. Enforcing the link ensures that the GPO will be executed no matter what downstream GPO’s are applied to downstream containers. This provides an exception to Rule # 1 on Execution Order. The proper application to this is an upstream link. Note that Enforced is applied to the link, meaning the should GPO may be linked to more than one container, only those that we applied Enforced are those that will be enforced. Enforcing the link is a powerful exception that overrides the Block Inheritance exception

Rule 5 – GPO Access Control. If, for example, one would intend to enforce a specific GPO only to a subset of user accounts in an OU, we only need to change the default Access Control List of the GPO to allow both Read and Apply Group Policy to those user accounts that need to be enforced with the policy (we need to remove Authenticated Users from this ACL in the process). On the other hand, if we wish that a specific subset of users, say for example, Administrators SHOULD NOT be enforced with, say for example, a restrictive GPO, then we can just grant them Deny permissions on Apply Group Policy. Note that the Enterprise Admins, Domain Admins and Administrators groups are not subject to Group Policies because these group accounts are not given the Allow permission in Apply Group Policy permission by default, but they are also not explicitly given a Deny permission. This means that, making a user account a member of these groups does not necessarily liberate that user account from restrictive Group Policies. For really restrictive policies that endanger an administrative account being locked out, it is best to explicitly give the said group accounts the Deny permission on the Apply Group Policy access control entry.

Key pointers in designing and implementing Group Policies

  1. Although one can link a GPO to the Site container, it is not adviseable, given the fact that a site can contain multiple Domain Controllers from different domains.
  2. As mentioned in the OU Design document, implementing a wide but shallow OU structure is better than a narrow but deep structure for performance purposes. The deeper the OU, the more Group Policies that need to be processed and the longer it takes to start up the machine and/or log on the user. Although a wide but deep structure would eventually mean more GPO’s and more links, less GPO’s need to be enforced during the startup or logon process.
  3. Ensure that the Distributed File System (DFS) is working properly between domain controllers in the same domain. DFS is the means for the Group Policy files to be transferred between domain controllers. If DFS is malfunctioning, it is possible that multiple, copies of the same GPO get propagated and enforced on the client machines. Depending on the nature of the GPO, this can pose a serious security threat to the network.
  4. Download and install the Group Policy Management Console (GPMC)
  5. Learn the proper usage of Block Policy Inheritance and Link Enforced. Refrain from using these exceptions if you can get away with it. Remember: Block Policy Inheritance is applied to a downstream container, while Link Enforced is applied to an upstream Link.

The Group Policies design caps off our series on Active Directory Design. For more information or comments, feel free to get in touch with me using the email address below.

Written by jpaloma

January 19, 2011 at 11:38 AM

Active Directory Organizational Unit Design Principles

with 13 comments

This blog entry was written on July 2006. Since much of it is still relevant in today’s Windows Server 2008 R2 Active Directory, I took the liberty of reviewing and reposting it in my new techblog. – Jay Paloma

Organizational Units (OU’s) are containers within domains. They are the elements of hierarchical structure within domains

Photobucket - Video and Image Hosting

Characteristics of the Organizational Unit (OU)

  • OU’s offer the best method to organize the hierarchical structure in Active Directory. There is a big temptation to reflect the organizational hierarchy in the domain, but as we learned in the Domain Design section, this is not a good idea. The Organization Unit would be best suited for the job.
  • OU’s can easily be renamed, moved, and deleted. Using Active Directory Users and Computers (ADUC), manipulating OU’s can easy. Renaming the OU does not affect the objects inside that OU. Moving the OU moves all objects and containers inside that OU. Here’s the tough one: deleting the OU deletes all containers and objects inside that OU. So better be careful!
  • Maintaining the organizational hierarchy using OU’s has less impact on performance compared with maintaining it in domains. While the domain requires at least an addition of at least two domain controllers per additinal domain, the OU does not have that requirement. Additional OU’s also don’t have additional replication overhead, well, enough replication overhead to replicate the hierarchy of the OU in the domain, but that’s it.
  • Organizational Units are bound within the domain. All organizational units do not exceed the domain boundary. Similarly named OU’s in different domains are independent of each other. To put it in another way, all domain controllers in the domain contain the same set of OU’s for that domain, and only for that domain.
  • The OU offers a good administrative boundary. Permissions to Active Directory objects can be delegated at the OU level, and have them inherited in the containers and objects inside that OU.

Reasons to create Organizational Units

  • Delegate administrative control. Administration of Active Directory objects can be done in a per OU level, and these permissions by default are inherited by containers and objects in the said OU.
  • Implementation of Group Policies. Group Policies can be implemented, among others, on the OU level. Like administrative permissions, they are also inherited by downlevel OU’s and objects. We will take a look at group policies in the next section.
  • Object organization in Active Directory. The Active Directory domain can contain millions of objects. It may be very hard to locate for a specific object among millions if there was no mechanism to organize them.

Some OU design principles

  • Simplicity is (still) the key. Although we can create as many OU’s as we need, it would be important to make sure that they are in the simplest way possible. A domain with hundreds of OU’s may no longer be supportable. Also, the deeper the OU structure, the longer it takes for a computer to start up or a user to log on because of processing of Group Policies in the depth structure of the containers. A general rule of thumb is an OU structure that does not exceed a depth of 5 OU’s (3 is a conservative figure).
  • Have knowledge of the Customer’s political and organizational structure and boundaries. It is important that the organizational and political structure of the Customer is to be understood by the infrastructure architect from day one. As mentioned, we can move objects from one OU to another. However, doing so would change the object’s group policies applied to it, and may not be a wise move after rolling out the said GPO’s.
  • Consider separating the user from the workstation. In the next section we’ll take a look at Group Policies, and we will learn that there can be separate Group Policy Objects (GPO’s) for User and Computer objects. This makes it possible to also separate the computer objects from the user objects accessing them, since there might be a separate group of administrators managing them anyway.
  • Consider separating the service from the server. In the same way that user objects can be separated from their workstations, the services can also be can be separated from the server. This is because Group Policies can also control which services are running on a specific machine. Example, all computer objects of web servers running IIS can be placed on one OU, and apply to that OU a Group Policy Object that ensures that the World Wide Web Publising Service starts automatically on those servers, while is Disabled for the rest.

Be careful with complex OU structures

Have a principle on OU design, at least on the top levels of the OU. This way, objects won’t get “lost” in an intricate and highly complex OU design. It’s very easy to “lose” an object after creating a complex OU hierachy with matching delegated permissions to boot, by successfully finding an object in the Find function in ADUC, but not being able to access the same because delegated administrative control bars the currently logged on user from accessing either the object itself or the container (or one of the containers of the container) holding the said object. In other words, the object exists, but is not accessible, and uniqueness rules prevent us from creating a similarly-named object.

A popular OU Design

Quite a number of companies I’ve worked with follow this OU hierarchical model (see picture above): the topmost level is is the geographical locations, then the layer under that would be the administrative types (servers/workstations/user accounts). Two levels, some more than two, but more or less following that pattern. This model offers the benefits of having a geographically independent set of administrators, and sub-administrators for each geographical location managing user accounts, servers and workstations. Administrative control can be delegated off to the geographical administrators, and at the same time to central administrators if ever a centralized administration is preferred.

The same is true for Group Policy implementation. A central group policy applied at the domain level or separate group policies applied separately for OU’s in either the geographical or administrative OU levels make it centralized, or decentralized respectively.

In short, this model enjoys the possibility of having either centralized or decentralized modes of administration and group policy application. If your organization is one that has multiple geographical locations per domain, consider this model.

Written by jpaloma

January 19, 2011 at 11:31 AM

Active Directory Domain Design Principles

with 3 comments

This blog entry was written on July 2006. Since much of it is still relevant in today’s Windows Server 2008 R2 Active Directory, I took the liberty of reviewing and reposting it in my new techblog. – Jay Paloma

Ater you finalize the Forest Design, it’s now time to consider how the Domains will look like in Active Directory.

The key to domain design is to start with a single domain, then justify the need for an additional domain. Domain design principles in Windows NT 4.0 and earlier are already irrelevant as far as the Active Directory is concerned, so don’t be tempted to create a new domain for each business unit or branch office that the company has, or for each set of administrator that the company has.

So, what are the reasons to create additional domains? It is my personal recommendation, as well as Microsoft documentation,  that each additional domain should have one or more of these conditions:

When business units have different domain-wide security policies. An example of a domain-wide security policy is password length. If a certain group of users wish to have a minimum password length of 8 characters, while another group of users prefer 4 characters, then it leaves us no choice but to create a domain for these two groups of users. Other domain-wide policies include password complexity, account lockout and Kerberos ticket lifetime. (NOTE: Password policies are no longer bound within the domain -jp 18 jan 2017)

When different locations cannot support bandwidth for Domain Partition Replication. In this scenario, we need to isolate the domain partition for each LAN location by creating a domain for each location. The domain partition is one of three partitions (the others are the Schema and the Configuration partitions) containing user credential information, among others. Although Active Directory replication uses IP or SMTP to transfer data from one domain controller to another, the Domain Partition is always replicated via RPC and is encrypted for security (it replicates usernames and passwords, that’s why). What is needed is not necessarily bandwidth, but more on availability. Therefore, if two locations have intermittent WAN link downtime, create a different domain for the remote location.

When doing an in-place upgrade of a Windows NT multiple domain environment. An in-place upgrade may result in the creation of a new domain, and this domain may not qualify in the conditions to create a domain mentioned above. If this were so, after doing the in-place upgrade, consider consolidating the domains if the benefits outweigh the risks in the consolidation process.

The reasons NOT to create new domains are as follows:

Administrative considerations. If each business unit has its own domain and its own set of administrators, the solution in Active Directory is not to create an additional domain, but to create Organizational Units for each business unit and delegate administrative control over those business units to the appropriate personnel.

Windows NT Object Limit. In Windows NT, the maximum number of objects for each domain is 40,000. This is no longer true in Active Directory. The practical limit of the Active Directory database is the hard disk size. To put it in another way, given the proper hardware, it is possible to create a user account for all Filipinos in a single domain, and the domain controllers can still do their jobs properly as what’s expected from domain controllers.

Primary Domain Controller (PDC) Availability. In Windows NT 4.0 and below, there is only one writeable copy of the domain database, and that’s in the Primary Domain Controller. If a domain were to have to or more sets of administrators making changes to the domain database from two locations, it is better in Windows NT to separate these two sets of administrators in two domains to make a PDC more available near their location. In Active Directory, the concept of Primary Domain Controller no longer exists. All domain controllers have a writeable copy of the domain database already. That’s why in the above scenario, the domain database will be written on the domain controller(s) nearest to the administrators.

Namespace requirements. It is not a correct practice attempting to reflect the organizational hierarchy in Active Directory domain names, and thereby in the Active Directory domain structure itself. If it is really a must to reflect the hierarchy of the company in the directory structure, the Organizational Units are more appropriate for the job. Even Microsoft Exchange email domain names are not to be reflected in the domain hierarchy, because such is the responsibility of the Recipient Update Services or RUS.

In a multiple domain scenario, you may want to consider the domain naming hierarchy. Here is where Active Directory Domain Trees come in. A Tree is simply a group of domains sharing a contiguous namespace. If the top of the tree is called mycompany.local, and its child domains are manila.mycompany.local and subic.mycompany.local, then these three domains form an Active Directory Tree. It is important to note that having mycompany.local as the parent domain of subic and manila subdomains does not empower its administrator to administer its child domains.

Active Directory Domain Tree

Creating additional domains joins these domains into a two-way, transitive trust relationship with the other. This trust relationship cannot be altered or removed. It’s simply there. The trust relationship is transitive, meaning if A trusts B and B trusts C, A has an implied trust relationship with C.

After considering the single domain, multiple domain, and in a multiple domain scenario, how these domains are to be organized, it’s time to consider how we’ll organize object within a domain. That will be the role of the Organizational Unit (OU), and that’s discussed in the next section.

Written by jpaloma

January 19, 2011 at 11:30 AM