1dent1ty cHa0s

Continued from part 1...

Figure 1

So, as shown in Figure 1, attributes are assigned to auxiliary sub-classes and sub-classes are combined to help define extensions to a structural class. When new objects of the structural object type are instantiated they inherit the structure defined by the combination of the class, sub-classes, and component attributes. By creating new auxiliary classes and linking new attributes to them you can extend built in classes like Users, Groups, and Computers, but how do I restrict access to a subset of attributes? Access can be controlled by attribute, but for the greatest flexibility you will likely want to use a Property Set; especially if you have more than a few attributes to extend.

Property Sets Defined

Property Sets in Active Directory provide two important features - they organize a set of like attributes into a convenient grouping and they control access to the attributes defined within using a single ACE entry instead of individual entries per attribute. You've probably already seen a Property Set but just didn't realize it.

Figure 2

In Figure 2 we see an example of Property Sets - Account Restrictions, General Information, Group Membership, Logon Information, and Public Information (there are more as well not shown) as displayed are all Property Sets that define access to a collection of attributes. It is important to notice that each Property Set is displayed as a set of Read and Write entries in the list - there are not discrete Read Property Sets or Write Property Sets and you don't create them that way.

Take for instance the Personal Information Property Set, this collection controls access to 41 attributes with a single click! So, how are the attributes linked to Property Sets? We understand how attributes link to sub-classes and how sub-classes link to structural classes, but where are Property Sets defined?

Property Set Relationships

Property Sets, unlike attributes and classes, are not schema attributes at all but are a special type of object called a controlAccessRight object that lives in the Configuration Naming Context under the Extended-Rights container as shown in Figure 3.

Figure 3

Well, that's where they live, but how are they related to attributes? Remember that GUID Converter Tool I told you about in Part 1? You'll need that tool to confirm the relationship but essentially there are two attributes that refer to one another. The Property Set's rightsGuidattributeSecurityGUID property. If you take the rightsGuid as displayed in Figure 4 and place it in the GUID Converter Tool (Figure 5) you can see what the Octet String version looks like:

Figure 4

Figure 5

Now when we look at an attribute with the Property Set and view it's attributeSecurityGUID property (Figure 6) we see they are the same and effectively linked:

Figure 6

So, an attribute's attributeSecurityGUID holds a SID that is the same as the SID specified in a Property Set's rightsGuid. These are not pointers per se and you should note that these are single valueed properties so an attribute can only ever be a member of a single Property Set at a time. The GUID Converter Tool also provides us the LDIF and LDAP versions of the same GUID so we can place this value in an LDIF script and an LDAP query respectively!

Later on you will have less difficulty defining your own Property Sets if you can keep the relationship and GUID types straight. In part 3 we'll talk more about Default Permissions for Authenticated Users and the Pre-Windows 2000 Compatibility Access group. These two groups make restricting access to sensitive data difficult.

In the world of Identity and Access Management, and in virtually every MIIS implementation, it is expected that you will be flowing some sort of interesting data OUT to a data source. In most situations this will involve populating Active Directory and in many cases you’re flowing data out that doesn’t fit inside a ready-built AD schema attribute. If you’re tired of writing data to Extension Attributes because you’re afraid of extending the schema then read on! But most importantly, we often take for granted the fact that we’re writing and publishing that information out to a public data source for the world, or at least everyone in your company, to see. In many situations the data we’re allowed to get from HR or other data sources is public anyway, so it’s not typically an issue, but in certain cases the need to protect confidential or private data is critical. I was just faced with this challenge recently and I thought I’d share what I’ve learned given that information and practical experience was a little short in the community.

Prerequisites

Before you even think about extending your schema, you will want to complete the following:

Enterprise OID Assignment - If you don’t already have one, obtain an Enterprise OID extension for your company; you must have a unique OID number for every extension you add. Registration with IANA is free and typically takes a few days. Here is their registration page: http://www.iana.org/cgi-bin/enterprise.pl

OID Assignment Management - Create a process and or team to manage your OID extension. You will need to plan on how your assignment will be allocated or else you’ll be in trouble later on. Also, make sure there is one place to go to register internally for extensions whether they are for applications developed internally, extensions marketed externally, or schema attributes used internally.

Documentation - Read the documentation! See the Reference section at the end for the important links to the AD Schema documentation. You may not understand everything the first time through, but you need to be exposed to it. When building your extensions you will refer often to several of the decode tables in order to determine the proper settings for bitmasks like searchFlags and systemFlags.

Tools

You’ll want to have the following tools handy to complete the extension planning and implementation:

Windows Server 2003 Administration Tools (Adminpak.msi) - You will need the Active Directory Schema and Active Directory Users and Computers snap-ins at least. If you do a full install of the AdminPak it will install all of the snap-ins but you can install them independently if you have the patience (I’m lazy).

Windows Server 2003 Support Tools - You’ll need the ADSI Edit snap-in and LDP.EXE for some operations.

ADAM SP1/R2 (optional) - Download and install ADAM SP1, or if you have Windows 2003 Server R2, install the version of ADAM that ships with it. ADAM SP1/R2 ships with an updated version of LDP.EXE that you can use to set Control Access permissions if you end up using the Confidentiality Bit.

GUID Converter Tool (http://directoryprogramming.net/files/default.aspx) – Provided by the authors of “The .NET Developer’s Guide to Directory Services Programming”, this little gem is invaluable if you’re going to build Property Sets or document/script your extensions in LDIF. Get it (the tool and the book)!

Planning

When you’re dealing with your schema and attributes that you’ll have to live with for the life of your forest, you’ll want to make sure you spend more than a few minutes planning it out. Stop to consider the following items:

Confidentiality - Decide whether or not you have confidential data you need protected. If you do not have to protect against Read access to attributes then the entire process is much simpler. If all of your Domain Controllers are Windows 2003 with Service Pack 1 applied then you can make use of a new featured called the confidentiality bit!

Usage - Review the current usage of schema by applications both Microsoft and 3^rd party. For example, if you intend on placing an employee number in your directory but applications expect it to be in employeeID or employeeNumber and you’re planning on creating a new attribute to store it then you will limit the value of your extensions. Find out if any applications make use of the already provided schema attributes for any enhanced features – chances are you may already be aware of these if you’re working with MIIS anyway. Also, don’t forget that LDAP directories are tuned for efficient reads not writes. If you’re going to be writing information to these attributes frequently then consider moving them to a specialized ADAM instance or better yet, a SQL table.

Indexing – Indexing frequently used or searched for attribute can dramatically affect the performance of the directory. If you think your applications will be frequently searching for particular attributes, then you’ll want to index them. Windows 2003 also introduces some new indexing types that will improve containerized and wildcard searches that you’ll want to evaluate. Also, if you’re in a multi-domain environment you will want to consider whether or not these attributes should be replicated to a Global Catalog. Replicating additional attributes to the GC will increase the size of the partial NC the other domain GCs will need to host.

Typing & Capacity - Plan your extensions diligently – both for the size and data type of each extension as well as its usefulness. You’ll want to make sure the size of the data you’re placing in the object you’re extending won’t increase the size of the object to greatly. You should have a rough idea of how much data you’ll be adding and per extended object in order to assess the impact on both initial replication of that data as well as increased storage requirements for the NTDS.DIT file. When choosing your data type (syntax in schema terms), don’t over think this – if you find yourself unsure as to which one to use you can generally pick Unicode String (2.5.5.12) as a fallback. Unicode string is both case-insensitive (nice for searches) and is capable of holding anything from the Unicode character set so you’re making sure it’s regionalization friendly. The other ones you’ll typically use are: Boolean (2.5.5.8), Distinguished Name (2.5.5.1), and Integer (2.5.5.9).

Extending Existing Object Types

I’m going to focus the subject of this posting to the extension of existing objects in AD – primarily the user object as that will generally be the most common type of administrative extension. If you’re an ISV and writing your own AD-integrated applications then you’re likely working with completely new object types and are beyond the scope of this post.

So, when extending the User class object, you’re really talking about modifying an object of class classSchema of the structural object category (objectClass = classSchema, objectCategoryType: 1). There are three category types here – structural, abstract, and auxiliary (all classes). We can add new or existing attributes (objectClass: attributeSchema) to an existing structural type (like User, Group, or Computer), or create our own abstract or auxiliary type class to hold the new attributes and then add the new class to the structural class (classes can inherit the attributes of a sub-class and anything that hold or defines something else is considered a class). I can’t say whether or not using another class to hold your attributes is necessarily best practice or not, but I would recommend doing so and not adding attributes directly to any pre-built classes. This should serve to make your extensions a bit friendlier and easier to add to other classes should you have the need to. After all, adding one auxiliary class with 40 attributes is easier than adding 40 attributes to the user class! We’re not going to talk about the abstract class or what it’s used for, so we’re going to concentrate on using the auxiliary class exclusively because of the added options it gives us.

Figure 1

As shown in Figure 1, the user schema object can directly contain attributes or contain auxiliary classes which in turn contain attributes of their own (Figure 2). Note that object classes have a defaultSecurityDescriptor which dictates the default security an object of this type will inherit when it is initially created – this does not affect security on existing objects.

Figure 2

In Figure 2 we see that an auxiliary class looks much like a structural class but we add our attributes here instead. Also, make note of the schemaIDGUID property – you’re going to need to know more about this if you’re using Property Sets later on.

In Figure 3 we see the attributes themselves defined with all of its bitmasks and type settings to well define the use of this particular attribute. Note that attributes themselves do not have defaultSecurityDescriptors as they cannot exist on their own.

In parts 2 and 3 we will discuss the use of Property Sets and talk more about what default security aspects of Active Directory will confound your ability to restrict access to certain attributes.

It’s been five years now and I can look back over that nightmarish month that provided both a career high and a personal low. During America’s most horrific hours I experienced some of the most influential moments of my career and the ending of my first marriage. I’m talking about how 9/11 affected my then employer – American Express, my personal life, and the lives of those around me.

While at American Express I worked for Global LAN Systems Engineering (GLSE) – a team more or less dedicated to defining the standards for Windows based non-web facing technologies and infrastructure. I and my partner Mark Vinsen were responsible for architecting the new Active Directory infrastructure, writing all of the standards, building the core infrastructure, and testing the new features. By September of 2001 we had succeeded in doing a lot of testing, and a lot of documentation, but very little in the way of deploying anything other than our new empty root. American Express, being the large multi-national financial institution it is, is very slow to adopt new IT infrastructures; after all, IT is not its core competency and whether or not you’re running eDirectory or Active Directory doesn’t impact the way card members utilize “The Card”.

Early on, Mark and I had decided to split the Architecture so that we could each focus on specific related technologies. Mark took all things AD Services, which was principally Group Policy and OU Design. I took all things Infrastructure Services related which kept me where I was happy – DNS/WINS, DFS, Forest/Domain Design, and what would become Identity Management. You see, I had caught wind of another team within Amex who was working on deploying Microsoft’s Metadirectory Services (MMS) and integrating with HR and the principle service directories. I recognized early on that allying with this “Metadirectory” team would seriously influence the design of the Active Directory and offer some serious TCO down the line; little did I know that it would prove to be a key success story for disaster recovery as well.

On the morning of September 11th, 2001 I was driving in to Scottsdale to attend a Cisco CCNA training course (part of my self inflicted IT diversity) when I heard the announcement. Arizona being three hours behind we had already missed most of the early story so we were trying to catch up to the rest of the country who had already been staring at the smoldering buildings for some time now. I never did finish that training class – I returned to work in order to help plan the Disaster Recovery efforts; ~6000 American Express employees working in the World Financial Center were now displaced.

The next few weeks were a blur – I remember there essentially being two options before us, attempt to restore what had been there (an aging NT4/Win9x and Novell 3.x environment) or move forward with Active Directory. I remember being asked if we could do it, and a rare and risky chance was taken to move forward – all eyes were on us to deliver something short of a miracle in a short span of time.

The solution consisted of a high powered Citrix farm, supported by pristine new Windows 2000 File/Print clusters and our newly built Active Directory domain with Thin Clients being installed at the remote locations being provisioned. Jason Willey (GLSE Architect) managed to design a pretty kick-ass Citrix environment and he and Glenn Haggard (GLSE Architect) drove a top notch team from Compaq to deploy the servers and build the standard desktops that the employees would utilize. Mark, myself and a whole cast of GLSE Architects and members from other teams pitched in to get all of the infrastructure components into place (Network, SAN storage, OS Builds, and the day to day support). I can remember walking around in my own shadow world, consumed by architectural diagrams, white board drawings, and my Nomad Jukebox to help tune out the world so I could focus and make it through the 20 hour days. I remember being stopped in the hall or being called into a meeting by some executive manager four or five levels higher than I to make some split second decision on some bit of the implementation – all the while trusting in our team to make this work, to restore operations, and to restore shareholder faith that the company would continue to operate after loosing its world headquarters. I also remember the way my body decided to deal with the sudden onset of all of this stress. I remember throwing up much of what I ate, and as a result, not eating much. When I managed to grab a few hours sleep I was plagued with nightmares about what had to be done – I was possessed by an overwhelming need to complete the task that we had asked for (and a nagging wife to stay at home)…begged for even, the chance to do our little insignificant part to help those affected. We knew we couldn’t be there, we couldn’t make a difference like the true heroes did, but we could do everything in our power to affect the things around us.

Despite that looming horror and uncertainty, I have to pause for a moment and tell you about our little Road Warrior crew. Three of the members of our team volunteered to drive a rental van to New Jersey so we could deliver some critical server and network components to some of the locations and give a hand trying to get local operations back on track. George Middendorf, Michael McGibbney, and Steve Richins made the trek and saw Ground Zero first hand. They saw the shock on the faces of our co-workers who were in the tower when the first plane hit, and who were all working diligently to restore service, and to take their minds off of what had happened. Remembering those guys driving all that way to lend their support always brings a smile to my face. I like to think that having their personalities and expertise there onsite after such an unthinkable tragedy helped to lift spirits.

So, MMS – yes, our little unsung hero, and the folks on the Metadirectory Services team (Attila Erdos and Neville Lee) had managed to secure access to all of the HR data we would need but we hadn’t yet had time to work on the ADMA. So, I asked Attila to provide us an LDIF export containing all of the New York and New Jersey employees provisioned into some location specific OUs. In a few minutes I was able to load all 6,000 employees into Active Directory (LDIFDE) – MMS had done the really hard work in defining who was affected, had clean data and pre-built sAMAccountNames all ready for me to work on. Once we had all of the accounts loaded, it was up to Mike Kasher (Lotus Notes Consultant) and me to prepare the accounts for their entitlements: home directories, terminal server profiles, and Notes ID files. In what would have taken me a few hours to configure with the new Notes and AD MAs it took Mike and I a marathon 40 – 60 hours (2+ days) to script and execute. Finally, all of the pieces started to fall into place. New facilities had been procured and were being appointed. The network carriers were busy running nice big pipes to the new facilities. Compaq was drop shipping a ton of new Thin Clients, and arrangements were being made to ferry all of the displaced employees via train and bus to the new locations. In the span of about three weeks we and the other teams had accomplished the seemingly impossible – we had built a completely new infrastructure from the ground up. Everything from buildings, power, network, furniture and chairs had been procured and installed. Everything back in Phoenix had come together and was operating; a completely new Citrix and Active Directory environment with over 6000 ready to use accounts were ready to access new virtual desktops secured by GPO, to send and receive email, and to use their basic Office applications. Another team was already busy restoring the terabytes of backed up data from tape and still another team was well ahead into prioritizing and restoring all of the localized business critical applications. MMS had played a critical role in restoring service and is one of the many un-sung heroes of American Express’s 9/11 Disaster Recovery.

In the aftermath we had a lot to consider – how had we been able to accomplish so much in the face of tragedy and adversity when we normally spent months or even years attempting to implement projects of this magnitude? To this day I joke that it took terrorists to crash a plane into a building before we got the go ahead to implement AD, but it’s not far from the truth. What we had experienced was a moment of horrific clarity, where everyone for a brief moment in time was focused on a single task; a feeling an entire nation shared post September 11th. No one stopped to question why, to throw procedure in our faces to slow us down, or sabotage us for their own personal or political gains – we just did had to be done, we did was right and it worked.

In my own personal aftermath, after experiencing such a career high I experienced the ending of my first marriage. Instead of having the understanding and supportive wife I have now who would have been there for me done whatever it took ease the burden, I had quite the opposite. The terrorists are responsible for one good thing at least – they ended what was already a failing marriage and made it terribly clear that I could no longer live the way I had been.

So, after my cathartic spiel, I pause to remember those who were affected by this senseless tragedy. I take many lessons away from this experience, not the least of which is an appreciation for teamwork, both professionally and intra-marital as well as my newfound love of Identity Management technologies and how they serve to make our lives just a little bit easier.