Dreez's
PKI Single Sign-On Project

Active Directory Infrastructure

Revision Control

Contact Dreez: mje@secev.com

Overview

VPNs come in two flavors:

1. Site to Site - Two remote sites setup a VPN between themselves. This usually involves a one-time setup between two routers or two VPN servers. This type of VPN authenticates another machine strictly at the machine/IP level and does not involve authenticating any users.

2. Client VPNS - A traveling user(person) requires access to internal systems and uses a VPN from a hotel room to access corporate information. These clients are dynamic in nature (many setups, teardowns) and involve authenticating a person/user.

With most VPNs that support VPN clients, there has to be a username database that contains a list of users that will be authenticating to the VPN. The one thing we need to avoid is duplicating username database information. If a person quits, we only want to delete that person once. Therefore it would be best if the username database for the organization is the same username database for the VPN.

There are multiple places to store the VPN username database on the server side:

1. Internal to the VPN server in proprietary format

2. A remote RADIUS/TACAS server

3. An LDAP directory server

But only an centralized LDAP directory server has the capability to store usernames for the centralized networked OS (NT PDC, W2K Active Directory, Novell NDS, Unix LDAP, etc) as well as any tangent applications like VPNs. This LDAP server will answer queries for all applications as well as logging local clients into the target OS.

NT 4.0 and Exchange 5.5 supported the most minimal LDAP configuration possible. W2K supports a much more robust LDAP interface to Active Directory. Active Directory replaces NT 4.0 domains (username databases) and is highly integrated into most W2K applications.

Active Directory LDAP Overview

There are many great references on LDAP, so I won't go into detail on what LDAP is about. These are my references. In order to understand this section you need a clear understanding of classes (structural, auxiliary, abstract) , attributes, and containers. 

WARNING: If you intend to go it alone on Active Directory modifications and you do not know anything about Active Directory I highly recommend getting an experts advice. There is no going backward. So if you are playing with operational systems, please be careful. Even with my knowledge of Active Directory I have made mistakes that would of been fatal on operational systems.

The one thing to remember about AD LDAP, is understanding how the directory is organized. There are 3 big components:

1. Schema Definition - The directory schema defines the organization of the directory in an object oriented fashion, which means building objects through inheritance. So imagine defining an ice-cream cone recipe. You have nuts, cones, flavors that you are all mixing together to write a recipe. You do NOT have a physical ice-cream cone, only the recipe for one.
   
   Microsoft has defined a basic schema for you already. You can view the schema with the Schema tool found in the MMC administration snap-in. This tool lists all the classes and attributes in Active Directory. Remember the schema is only the recipe/ structure for what the directory will look like. There are no users defined in the directory. So in the diagram below you won't see a users name, but only a template for holding information about users.
   
   

Most of our work will be centered around the "user" class. We will be extending the "user" class to include new information for VPNs.  In the diagram above, you can see I have already extended the "user" class with all the VPN attributes and classes for Firewall-1.

2. Directory Containers - Active Directory has 3 storage areas within it:

   1. Schema container - Holds information about the schema

   2. Configuration container - Holds information about the directory such as where sites are located in order to replicate the directory, how to build a administrative GUI to look into the directory,  security access information, applications that access the directory, etc.

   3. Domain container - Actual database that holds information about your organization such as users, computers, internal OUs.
      
      
      The ADSI Edit tool found with the Microsoft Resource kit  is used to browse the contents of the containers. Below you can see the containers and some of their internal contents.
      
      
      
      
      
      

3. Directory Contents - This component is the actual information that you create and store into the directory. You use the schema as a template to build the information and then populate the directory with that information. For example, you use the "user" class to build information about a user (name, email address, certificates), create an object to represent the user, fill in the fields with user information, and then store the user into the directory contents. In the case of Active Directory, the directory contents are stored in the Domain Container.
   
   
   The tricky part is differentiating between the structure of the schema (recipe) and the structure objects populating the domain container. They are not the same. Look at the figure below and compare the schema to the instantiation/creation and storage of a "user".

The user schema has a different structure than the actual creation and storage of John Smith. The user schema inherits attributes from its "parents". John Smith is stored under Users which is stored under Domain Controllers which is stored under the domain container.

The reason this is important is because the tool used to build the directory (LDIF), defines both the schema AND populates the directory in the same operation. So when working with this tool, you have to remember about which parts are working on the schema and which parts are working on the population of the directory. 

A quick word about LDIF and Active Directory. LDIF is two things:

1. A common LDAP standard which describes the format and syntax for an LDAP directory in a text file format. Sort of like saving an Excel spreadsheet to comma-separated text file. 

2. A tool that reads LDIF files and populates LDAP directories

For example, the following LDIF entry adds a new attribute "fw1auth-method" into the list of attributes stored in the Schema container:

sample.ldif

dn: CN=schema,CN=configuration,DC=dreez,DC=company,DC=com
changetype: modify
add: attributetypes
attributetypes: ( NAME 'fw1auth-method' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

The following line imports the entry into AD, and creates a new attribute entry.

ldifde -v -i -f sample.ldif

Now, in case you are under the illusion that LDIF is LDIF is LDIF no matter what LDAP compliant product you are working with, then erase that silly thought from your head. I too once was under the allusion that AD was LDAP compliant and worked with all the standard tools like LDIF. That foolish notion was quickly dispelled as I dug deeper into the intricacies of AD. AD is actually a step closer to X.500 than other LDAP products, and so it requires more/different information in the LDIF file than a standard LDAP directory. So if you plan on working with LDIF files within AD, get ready for the long haul. Minimal documentation and minimal logging is the norm. 

Integrating Firewall-1 VPN into Active Directory

My approach to describing this integration will be a high level overview of the FW1 specific items in AD, and then the details of how to actually perform the work.

Checkpoint distributes an LDIF file  with their VPN product which describes all of the objects, classes and attributes associated with storing VPN information in a LDAP directory. Using this file to integrate FW1 and AD centers on two components:

1. fw1person class

2. fw1template class

The "fw1person" class contains all the attributes need to extend the standard AD "user" class to include FW1 user information. The following diagram shows some of those attributes.

The way I decided to enhance the user class, is by building a FW1 auxiliary class that contains all the FW1 attributes. Auxiliary classes are commonly used to extend a schema with new information outside of the OS specific information. This application of FW1 VPN attributes into a Microsoft environment is a good example of extending the MS AD schema with non-MS AD information. 

Once the FW1 auxiliary class is  defined, I force the "user" class to inherit the "fw1person" class. We will see LDIF examples of this in the following sections. Remember that at this point we are only talking about the schema (recipe) and NOT actually populating the directory with actual users.

The "fw1template"is a little different. There is no existing template in AD that needs to inherit fw1template information. fw1template is kind of a standalone class. Therefore, I create a "fw1template" class, which hold all the attributes for the template. I then associate it with the standard "group" class.

For those LDAP savvy readers, you are probably thinking "No problem, do it all the time". Well, let's take a look at how Microsoft LDIF is different from standard LDIF. Here is the same LDIF file but modified to support Microsoft AD environments - Microsoft FW1 VPN LDIF File. Compare a standard LDIF entry with a Microsoft AD LDIF entry for the exact same attribute entry:

Standard LDIF Attribute Entry

dn: CN=schema,CN=configuration,DC=dreez,DC=company,DC=com
changetype: modify
add: attributetypes
attributetypes: ( NAME 'fw1auth-method' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 )

Microsoft LDIF Attribute Entry

dn: CN=fw1auth-method,CN=Schema,CN=Configuration,DC=company,DC=com
changetype: add
adminDisplayName: fw1auth-method
attributeID: 1.2.840.113556.1.4.7000.233.28688.28684.8.56441.683419.1175504.1507414.1
attributeSyntax: 2.5.5.5
cn: fw1auth-method
description: fw1 auth
isMemberOfPartialAttributeSet: FALSE
isSingleValued: FALSE
lDAPDisplayName: fw1auth-method
distinguishedName: 
CN=fw1auth-method,CN=Schema,CN=Configuration,DC=company,DC=com
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=company,DC=com
objectClass: attributeSchema
oMSyntax: 22
name: fw1auth-method
schemaIDGUID:: GrzYymDU6U2q2XoG4P7/UA==
searchFlags: 0

Standard LDIF Class Entry

dn: CN=schema,CN=configuration,DC=dreez,DC=company,DC=com
changetype: modify
add: objectclasses
objectclasses: ( 1.2.840.113556.1.5.7000.111.28688.28684.8.186482.55449.1789935.822456.2 NAME 'fw1person' SUP 'top' MUST ( cn ) MAY ( description $ fw1auth-method $ fw1auth-server $ fw1pwdlastmod $ fw1skey-number $ fw1skey-seed $ fw1skey-passwd $ fw1skey-mdm $ fw1expiration-date $ fw1hour-range-from $ fw1hour-range-to $ fw1day $ fw1allowed-src $ fw1allowed-dst $ fw1allowed-vlan $ fw1SR-keym $ fw1SR-datam $ fw1SR-mdm $ fw1enc-fwz-expiration $ fw1sr-auth-track $ fw1grouptemplate $ fw1ISAKMP-EncMethod $ fw1ISAKMP-AuthMethods $ fw1ISAKMP-HashMethods $ fw1ISAKMP-Transform $ fw1ISAKMP-DataIntegrityMethod $ fw1ISAKMP-SharedSecret $ fw1ISAKMP-DataEncMethod $ fw1enc-methods ) )

Microsoft LDIF Class Entry

dn: CN=fw1person,CN=schema,CN=configuration,DC=company,DC=com
changetype: add
adminDisplayName: fw1person
cn: fw1person
defaultHidingValue: FALSE
defaultObjectCategory: 
CN=fw1person,CN=Schema,CN=Configuration,DC=company,DC=com
defaultSecurityDescriptor: 
D:(A;;RPWPCRCCDCLCLOLORCWOWDSDDTDTSW;;;DA)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)
(A;;RPLCLORC;;;AU)
description: FW1 person
governsID: 1.2.840.113556.1.5.7000.111.28688.28684.8.311545.1760683.2076778.619551.2
lDAPDisplayName: fw1person
mustContain:cn
mayContain: description
mayContain: fw1auth-method
mayContain: fw1auth-server
mayContain: fw1pwdlastmod
mayContain: fw1skey-number
mayContain: fw1skey-seed
mayContain: fw1skey-passwd
mayContain: fw1skey-mdm
mayContain: fw1expiration-date
mayContain: fw1hour-range-from
mayContain: fw1hour-range-to
mayContain: fw1day
mayContain: fw1allowed-src
mayContain: fw1allowed-dst
mayContain: fw1allowed-vlan
mayContain: fw1SR-keym
mayContain: fw1SR-datam
mayContain: fw1SR-mdm
mayContain: fw1enc-fwz-expiration
mayContain: fw1sr-auth-track
mayContain: fw1grouptemplate
mayContain: fw1ISAKMP-EncMethod
mayContain: fw1ISAKMP-AuthMethods
mayContain: fw1ISAKMP-HashMethods
mayContain: fw1ISAKMP-Transform
mayContain: fw1ISAKMP-DataIntegrityMethod
mayContain: fw1ISAKMP-SharedSecret
mayContain: fw1ISAKMP-DataEncMethod
mayContain: fw1enc-methods
distinguishedName: 
CN=fw1person,CN=Schema,CN=Configuration,DC=company,DC=com
objectCategory: CN=Class-Schema,CN=Schema,CN=Configuration,DC=company,DC=com
objectClass: classSchema
objectClassCategory: 3
name: fw1person
rDNAttID: cn
schemaIDGUID:: XPRj5AmmzEeUjELtvj1vQA==
subClassOf: top

For the sake of brevity, I won't go into details on all the different fields but will refer you to the Microsoft technet article which starts to describe some of these fields. For the purposes of integrating FW1 with AD, you do not need to know what all these fields are. You will only import these LDIF entries into AD and magic will happen. If there are problems with the import process, you will then probably have to dig into AD in detail and figure out which fields are giving you problems. The only two fields you really care about are:

1. attributeID/governsID

2. schemaIDGUID

These fields will have to be customized to your environment. I have gathered some tools to help you with this process - GUIDTools-Click Here. These are a combination of Microsoft tools and my own tools. 

The attribute/governsID field requires an object id and can be generated with Microsoft's oidgen.exe tool (for more info, read this). This tool generates the base OID for attributes and classes that you will use in your environment. You just start with and append ".1" and increment up to ".30" or so.

The schemaIDGUID field is not quite as easy. This field is a globally unique ID to your environment. This field is generated by Microsoft's uuidgen.exe utility. In the following example, we have used the uuidgen.exe tool to generate 5 GUIDs and store them into a file.

Unfortunately, AD does not like GUIDs in text format. It only accepts GUIDs in base64 format. So I have written a tool called guidconvert.exe which converts GUIDS into base64 format. You have to cut a GUID from the uuidgen.exe tool and paste it into the guidconvert.exe tool. guidconvert.exe will then generate the base64 format for the GUID. You can recognize this format because it usually ends with "==".

Misc. LDIF Entries

There are a couple interesting entries in the LDIF file that you should know about, but are not required to take any actions with.

Most standard LDAP implementations define a user with a uid attribute. This attribute usually stores a unique id for the user such as employee id, or social security number. However, Microsoft AD does not define a uid attribute. So we are forced to create this attribute in order to support FW1 VPN. This field is critical to FW1 VPN, because it has to exactly match the name in the X.509 certificate that VPN clients authenticate with. My worry is that this field may not support some future application that may use the uid field for some other purpose or try to store a value that is incompatible with the FW1 VPN format. 

dn: CN=uid,CN=Schema,CN=Configuration,DC=company,DC=com
changetype: add
adminDisplayName: uid
cn: uid
lDAPDisplayName: uid
distinguishedName: 
CN=uid,CN=Schema,CN=Configuration,DC=company,DC=com
name: uid
attributeID: 1.2.840.113556.1.4.7000.233.28688.28684.8.56441.683419.1175504.1507414.29
schemaIDGUID:: b94LSG+JD0OpbRRGstw20A==
attributeSyntax: 2.5.5.5
description: Netscape compatibability attribute, used for searching
isMemberOfPartialAttributeSet: TRUE
isSingleValued: FALSE
objectCategory: CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=company,DC=com
objectClass: attributeSchema
oMSyntax: 22
searchFlags: 1

Microsoft AD has a caching mechanism built into it. When working with LDIF files, if one LDIF entry refers to a previous LDIF entry there is no guarantee that the previous entry exists in the actual AD, it may still be in cache. So the following entry is required to flush the cache back to AD:

DN:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

I have warned several times about the complexity and danger of modifying AD. The following entry is the one that is the most dangerous. This entry ties the FW1 information into the Microsoft "user" class:

dn: CN=user,CN=schema,CN=configuration,DC=company,DC=com
changetype: modify
add: auxiliaryClass
auxiliaryClass: fw1person
-
add: mayContain
mayContain: uid
-

All other LDIF entries should not impact AD because they are just FW1 specific entries that AD will never use. One integration technique is to delete this entry until you are confident that things are working properly. Then when you are confident things are working, add this entry back into the file and re-run the file.

The Integration Process

At this point you should have a basic understanding of the contents of the Microsoft FW1 VPN LDIF.  The only need for an advanced understanding is if you are running the file against a production system and something goes wrong. Otherwise, aside from some minor modifications the file will install itself without further detail knowledge.

This is the process:

1. Run oidgen.exe and generate unique base object IDs for attributes and classes

2. Append a ".1" to each OID and generate a list of 40 attributes and 2 classes. So you should have ".1", ".2", ".3" etc attributes up to ".40". Same with classes (only 2 of them)

3. Assign an attribute OID to each attributeID field

4. Assign an class OID to each governsID field

5. Run uuidgen.exe -n 100 > uuidpool.txt to generate a list of unique GUIDs

6. Copy 1 GUID attribute, and paste it into the guididconvert.exe program to generate its base64 format

7. Copy the base64 format to a schemaIDGUID attribute. Repeat 6-7 for each schemaIDGUID attribute.

8. Save the file

9. ldifde -v -i -k -f ms-cp-ldif-1.txt will import and modify AD with FW1 information

Debugging

I recommend you start out with small experimental LDIF descriptions and work your way up as you understand how AD works with LDIF.  Here are some other tips:

1. After adding an entry, use MMC Schema tool to view its contents

2. AD LDIF leaves a log file in the current working directory, use it

3. AD LDIF has a -v verbose switch, use it

4. AD LDIF is case sensitive

5. AD LDIF does NOT NOT NOT like extra spaces where they are not needed,
   like attribute names.

6. The only Microsoft documentation that makes any sense is here.

7. Don't make any mistakes, or you won't be able to fix them. Its like working with ink in a wedding dress.

The best tool for debugging as you install items into AD is the LDP tool that ships with the resource kit. This tool makes remote LDAP queries to AD and returns information to you as any other LDAP client would see. If you ever have problems debugging the VPN LDAP queries, use this tool and a network sniffer to figure out why data is not being returned correctly.

Here are some quick start tips:

Connect to the appropriate LDAP server

You can start performing searches, but at this point you are only authenticated anonymously. If you want to perform more complex functions, I suggest you login as adminstrator. In addition, I suggest you login using "simple" login format. This format is the lowest common denominator for all LDAP applications. Note that you will have to specify a domain (e.g. dreez\administrator). Once this works, you can try higher forms of authentication. With LDP you can also do a Kerberos authentication using Microsoft's authentication model:

After you authenticate, you can perform almost any LDAP operation. But the one used most for debugging is searching. Here are some tips for searching:

1. When searching, use the Base DN names you learn from ADSI Edit or the MMC Schema tool.

2. The filter is typically an attribute/value pair that you are searching for. It does take some wild card characters. I

3.  suggest you search through the subtree recursively in order to review all objects otherwise you will just look at one level.

4. I suggest you return all attributes by specifying a "*". This returns attributes whether or not they have values associatd with them

Home | Services | Training | Support | Contact Us | Search

Copyright 2006, Security Evolution, Inc.