Active Directory as a Directory Service 1

Transcription

1 Active Directory as a Directory Service 1 A Structural Analysis of the Active Directory Architecture with Basics of ADSI Programming in C# and C++ Authors: S. Pinardi, E. Colombo, T.A. Aruanno, R. Bisiani 1 The authors thank Microsoft for the support material provided to write this monograph 1

2 Active Directory as a Directory Service 2 A Structural Analysis of the Active Directory Architecture with Basics of ADSI Programming in C# and C++ S. Pinardi, E. Colombo, T.A. Aruanno, R. Bisiani Abstract The goal of this paper is to present and analyze the architectural structure of the.net 3 and Windows 2000 Active Directory (AD) and to show how it supports the programming and administration model of an Active Directory. Active Directory is a directory service that collects objects and attributes in a tree structure and manages them through the LDAP protocol. We will show how AD is useful for the creation of a directory, for data representation and management and for supporting distributed programming. We will also include practical administration examples that were carried out with common tools and short programming examples written in C# (.NET) and in C++. These brief but useful examples are helpful for both the analysis and the modification of the Active Directory s content and can be used as a basis for a university-level course. Objectives Analysis of a directory service, programming support, support for a programmingsystem or distributed-system course, support for a programming lab. Method Presentation of the conceptual model, analysis carried out with readily available tools and with ADSI 4 programming examples in C# and C++. Concept Requirements Object programming, basic knowledge of operating systems, basic knowledge of Microsoft domains, basics of network knowledge, in particular TCP/IP and DNS, basic knowledge of the COM/DCOM model (to understand examples in C++). Operational Requirements C# or C++ programming knowledge, basic knowledge of Microsoft operating systems (deployment) and of Microsoft domains management (administration). Note For an explanation of the functional and operational structure of Microsoft domains, necessary for correctly understanding parts of this paper, please see the material listed in the bibliography. 2 Some of the product or company names appearing in this paper are trade-marks or registered trademarks of their owners. 3 This paper refers to version RC1 (build 3663). 4 ADSI is a set of COM programming interfaces that make it easy to build applications that register with, access, and manage multiple directory services with a single set of well-defined interfaces. 2

3 1. Introduction The architectural kernel of the Windows.NET/2000 operating system is very similar to the one in Windows NT 3.51, which was designed by D.N. Cutler at Microsoft at the beginning of the Nineties. No big changes were made to the kernel, the main ones being the introduction of some new features, like the cache manager, and some concept modifications, like job objects, which do not change the architectural model s substance to a great extent. In addition, Windows XP/.NET significantly improved the process startup (activation) method by reducing startup times 5. On the other hand, differences between NT 4.0/3.51 and Windows.NET/2000 are quite significant as far as the distributed components, whose purpose is to define the domain and the internetworking infrastructures, are involved. Diffusion of networks, due to the spread of Internet largely changed culturally and operatively the production model of modern companies; this led Windows.NET/2000 designers to emphasize and strengthen Windows NT s distributed characteristics even further. Along these lines, the most important change introduced by Microsoft from Windows NT to Windows 2000 was a directory service, i.e. Active Directory, the topic of this paper. 2. Active Directory as a Directory Service A directory service delivers data following a specific request submitted according to an agreed-upon syntax. Data in a directory service are stored in a database according to a specific organizational logic, e.g. locally or geographically distributed nodes in a tree, tables or simple files. Each organization conforms to characteristic models and provides specific advantages. A directory service could be best described as a program an agent whose purpose is to insert, store and retrieve information (kept inside a database), while offering the user methods to manage it. To this purpose, a directory service must provide an effective data access model that is able to keep its database consistent. Of course a database can be stored in a central location (some web databases are like that), or it can be distributed among several locations that are connected by cooperating agents (the DNS service is a typical example of such database and distributed service). In the latter case, data will have to be distributed and copied according to a logic that will maintain their consistency and will then have to be reassembled in compliance with the user s expectations. X.500 (CCITT 1988) is a well known directory-service implementation with a specific data management protocol called DAP (Directory Access Protocol), which includes its own transfer protocol. DAP has been redefined in 1995 (RCF 1777) at the University of Michigan by using TCP/IP for transferring data. This new, more flexible and concise protocol has been called LDAP (Lightweight Directory Access Protocol). Another well-known directory service implementation is Active Directory, whose design was inspired by the X.500 model and was based on LDAPv2 and LDAPv3 (RFC2251, etc.). Active Directory s data management logic and data representation 5 For further information, see the specific literature listed in the bibliography [10]. 3

4 logic share some characteristics, but they basically follow orthogonal and separate definitions. Although Microsoft based its design on the LDAP model as far as data management is concerned, they used an object metaphor to represent them, following the newest trend for database definition. 3. Directory Services: an In-depth View Active Directory (AD) is a directory service that is also used as a security database (password database). Thanks to Active Directory, the Domain Controller (DC) provides one single authentication point (Single Sign On, SSO) thus allowing the user s information to be centralized and guaranteeing that users have a consistent representation in the domain, independently of where the authentication takes place. AD also allows storage of different information that can be shared among users or among the domain s distributed applications, so that it can be retrieved and used. Active Directory is therefore an important and complex component of the domain. Active Directory defines the domain itself (what), its authentication boundary (where) and its security boundary (who can access it). This is a functional or high-level definition of this service. An architectural or low-level definition of Active Directory would instead describe it as a partitioned, distributed, replicated, secure and object-oriented directory service. In the following chapters we will have a closer look at these characteristics by analyzing the architectural details first in order to have an insight into the single functions and then by applying the acquired concepts to programming. 3.1 A Concise Definition In order to provide an overview of the single functions involved, we will first give a concise definition of Active Directory (AD), then go into the details of the single concepts Active Directory is a Directory Service Active Directory is a directory service, i.e. a service that provides specific information, located in a database, upon well-formed queries. The LDAP protocol allows interaction with the AD in order to create, modify and obtain information Partitioned Active Directory An AD directory service is a collection of partitions, otherwise called Naming Contexts; each partition corresponds to a portion of the directory service. AD elements (objects) can be stored within each partition. The AD objects themselves are pieces of information or contain information as attributes Object-oriented Active Directory Active Directory provides an object-oriented view of its contents; the elements that make up an AD are objects consisting of attributes. Objects and attributes are abstraction instances, in other words they are instances of predefined classes and are contained within a special partition of the directory called Schema. As it will be obvious later on, the Schema itself is an object, and the data it contains are themselves objects. The Schema uses objects to define its own abstractions. 4

5 3.1.4 Distributed Active Directory Partitions are not bound to a specific physical location, since they can be placed on different Domain Controllers (DC), but they are connected to each other according to a reference logic called knowledge that is used to reconstruct the directory structure itself Replicated Active Directory Some data, some objects within a forest are global (they refer to the whole forest), others are local (they refer to the domain). Global data are replicated (shadowed) on all forest DCs to provide better performance; due to fault tolerance and load balancing, local data can be placed on more than one DC. In addition, a service called Global Catalog collects and provides some of the data of the whole forest for more effective data retrieval. Several kinds of data must then be replicated in the forest when going from one DC to another and this operation must be secure, consistent and effective Active Directory is Secure Active Directory requires authentication before allowing access to its database and supports authorization for reading and writing data. Discretionary Access Control Lists (similar to those used on the NTFS file systems) are associated with each AD object to guarantee controlled access and better management. This topic will not be discussed in depth, because it is strictly related to administrative issues that are not relevant to this paper Active Directory Represents the Domain Despite the definition directory service, AD s main objective is to store all the information associated with a domain, including the password database. This means that AD is a directory service that can serve several purposes, including domain representation Active Directory, LDAP Server and DSA Domain Controllers are LDAP servers. The election protocol for Active Directory s data request, modification and input is LDAP, as defined in RFC 1777 (LDAPv2), RFC 2251, 2252, 2253, 2254, 2256, etc. (LDAPv3). LDAPv2 was used by Microsoft for the Exchange 5.x directory service; LDAPv3 is used for AD and for Exchange 2000 (which is integrated with AD). Other protocols are used to interact with the directory service: the DSA (Directory System Agent), AD s operating core, has different application interfaces. Now we ll proceed with a deeper analysis of each of the previously mentioned characteristics. 3.2 Active Directory is a Directory Service AD s information can be retrieved through some access points (services), called providers, that use different interaction protocols or correspond to different LDAP protocol implementations. 5

6 Provider LDAP: GC: Description Compatible with Lightweight Directory Access Protocol Compatible with LDAP, connection request is specified with a Global Catalog server Compatible with Windows NT/2000/XP/.NET systems Compatible with Novell NetWare Directory Service WinNT: NDS: NWCOMPAT: Compatible with Novell NetWare 3.x Table 1 A list of commonly used providers. In this paper we will only focus on the LDAP protocol that represents the chosen protocol for.net/2000 domains. We will then examine the providers that use it, i.e. GC: and LDAP: (some concepts related to the WinNT: provider will be briefly mentioned in the programming section) Tree Structure and Attributes Both AD and X.500 organize their data in a tree structure whose nodes are identified by names. Directory services like X.500 are based on the idea that data contained in the nodes are collections of attributes and that an attribute-based search is possible. In this way, the user can obtain specific, attribute-defined views upon the data, instead of obtaining a single piece of information, as it happens with name services (e.g. DNS). The difference between a name service and a directory service is comparable to the difference between the phone s white pages and the yellow pages. Information you look up in the white pages (the customer s name) does not belong to a category but is rather information that you want to transform into more functional low-level data (the phone number). Yellow pages serve a different purpose: subscribers are listed by category (dentists, restaurants, hardware stores, etc.) that can be grouped according to a characteristic they share; if you are looking for a specific information, you usually turn to this kind of book and start a search by category refining it until you get the specific data you are looking for (names, addresses, phone numbers, etc.). This is similar to what happens in directory services: if you enter information along with one or more attributes describing their characteristics into the database, your search will be carried out according to categories. Consequently, different views of the same database can be generated. It is therefore important for the data in the directory to be represented correctly and for the protocol that allows interaction with Active Directory to accept an attribute-based query by the user. 6

7 Fig.1 A schematic view of how an attribute-based query will show a tree database LDAP Request LDAP allows creation, deletion and move of an object, listing of a container s content, and so on. Later, a few programming examples will show how some of the LDAP functions can be used through ADSI (see Section 4.2.3). The focus here will be on the retrieval of information related to objects contained in an AD by utilizing a specific syntax that allows searching for directory objects and selecting them on the basis of their attributes. A well-formed LDAP query is an application message of SearchRequest (3) type made up of a set of parameters that lead to the following search criteria: Search base (or base object): It defines the basic location, i.e. the forest node or leaf, where the search must start; the location is defined by using an LDAP Distinguished Name (see Section 3.3). Search base is used to indicate the directory section where the search should take place. Scope: It specifies how deep the search should go. There are three kinds of scopes: base, one level and subtree. Base scope restrict the search to the search base; if, for instance, the search base is a container object, its attributes will be listed, but not its contents. One level scope takes the search just beyond the base object, excluding the base object itself. With subtree scope, the search will extend over the whole subdirectory (including the base object). Filter: It s used to single out the required elements in the specified tree section. Selection (or attribute description list): It determines which attributes of the selected objects are important 7

8 Directory Search base Base One level Subtree = node Fig. 2 Possible filter scopes. For a comparison with the SQL (Structured Query Language) expression SELECT <field> FROM <table> WHERE <condition> selection has functions that are comparable to <field>, search base and scope to <table> and filter to <condition>. In short, the former expression could be re-written as follows: SELECT <selection> FROM <search base> WHERE <filter> The purpose of a comparison with a simplified SQL query is to understand the role of appropriate expressions in LDAP query syntaxes 6. Anyway, the directory s operating core is not SQL, but LDAP (and at a low-level ISAM). See an example of a programmatic search in AD in Section Other important parameters can be defined by a Search Request, e.g.: Size limit: INTEGER (0.. max); a user can define a maximum number of elements to be returned from a search; 0 (zero) means no restriction. Time limit: INTEGER (0.. max); a user can define the maximum time, in seconds, for an answer to a search; 0 (zero) means no restriction. Types only: BOOLEAN; this establishes if the user wants the attributes name (TRUE) or also the relative values (FALSE). Syntax of a Filter This is the syntax of a filter: ([<operator>](<filter>)[(<filter>)...]) 6 In the appendix see the example of a search that was carried out with SQL-like syntax. 8

9 where <filter> = (<attribute><operator><value>) <attribute> is the attribute of an object <operator> is one of the values listed in the following table <value> is a value compatible with the attribute type Operator Description Type it applies to & logic And <filter> logic Or <filter>! logic Not <filter> = Equality <attribute> >= Greater Or Equal <attribute> <= Less Or Equal <attribute> = Approximately Equal to <attribute> Table 2. This is what a filter could look like: (&(objectcategory=person)(name=al*)) This filter returns all users (Person) whose name starts with al in the specified search base and scope. See RFC 2254 and for a formal definition of filters or for further information. Search Examples LDAP queries can be carried out with the csvde.exe tool. Csvde is a command line tool that can be found in system32 folder; it sends its requests to the directory via an LDAP message and generates a CSV output (Comma Separated Value). Excel usually recognizes csv extension files as comma separated files and reads them correctly; they can also be explicitly imported with a wizard (open menu). The csvde tool, by using Excel, allows a high-level view of the objects and a simple examination of its fields. When launching csvde without specifying any parameters, a help function is available that briefly explains its usage. Among the various switches that are listed in the help function, some are used to define the search criteria mentioned previously, i.e.: -d <search base> -p <scope> -r <filter> -l <selection> An output file must be identified and this can be done as follows: -f <output file> By typing the following expression at the prompt: 9

10 csvde -f UserDomain.csv -d dc=isqre,dc=net -r (objectcategory=person) csvde extracts all Users from the isqre.net Domain partition (defined in the d switch parameter) and saves them in csv format in the UserDomain.csv file. The scope is subtree, unless otherwise specified. If you write (objectcategory=*) instead of (objectcategory=person) all objects found in the isqre.net domain are listed. A similar operation can be carried out with the LDP.exe tool located in the Support Tools (see Appendix). Once LDP is launched, it must be connected to an AD by choosing the Connection/Connect menu. A request panel will ask for a server and an IP port; by leaving the server field blank, LDP will connect with the DC RootDSE. An authentication operation must then be performed (Connection/Bind menu); if the authentication fields (User, Password) are not filled out, credentials received from the parent process will be used (usually those of the current user). After authentication and after selecting the Browse/Search menu, a panel asking the user to select the search base (Dn Base), the scope and the filter (Fig. 3) will appear. Fig. 3 Search base, scope and filter selection in LDP. The LDAP Search Request shown in Figure 3 identifies all accounts of the isqre.net Domain partition whose name attribute begins with al. The Option button gives access to a little panel where further parameters can be set, like selection (label attributes), size limit, time limit, types only, chase referrals 7 and more. Some expressions used in the examples on how to make a query will be further explained later on; in particular, we ll discuss Distinguished Names in the next section. 3.3 Partitioned Active Directory Partitioning, replicating and distributing are closely connected concepts and the partitions, also called Naming Contexts, are at the base of AD s distributed architecture. Every effective multi-user service that is available to several thousand users and can contain a lot of data must be easily accessed and its data must be managed efficiently. 7 See Section

11 One single access point could create a bottleneck in network traffic, hence it would be a liability, whereas distributing the partitions on more machines would allow for better load distribution (load balancing). An excessively centralized management in large domains could lead to an unmanageable administrative load and increase the complexity of the administrative task, which grows in a non-linear fashion with the number of data that needs to be processed, while separating data in different partitions could reduce search and update costs. Consequently, partitioning a distributed database with no growth limits is a good architectural strategy Partitions Active Directory has a tree structure, but its partitions don t univocally correspond to single nodes. There are different types of partitions in AD (three at least) and several partitions can be grouped on the same Domain Controller (DC). In particular, there are three partitions on a Windows 2000 DC: the Schema and Configuration partitions that include global data (related to the whole forest) and the Domain partition which contains local information connected with the domain the DC belongs to. A new type of partition, called Application Directory Partition (ADP), has been added in Windows.NET. ADP s avoid unnecessary network traffic because they let the administrator choose which DC s of a forest must be replicated; therefore they are useful in distributed applications (see Section 4.2.5). Two of these partitions have been used by Microsoft for the distribution of data connected with the domain and forest DNS zones (i.e. DomainDnsZones, ForestDnsZones). Therefore there will be at least five partitions in a.net Domain Controller: Schema, Configuration, Domain, DomainDnsZones, ForestDnsZones, and other possible Application Directory Partitions. Schema Domain Controller Configuration Domain 2000 Domain Naming Context s DomainDnsZones ForestDnsZones Directory Partition... Application Directory Partitions Naming Context.NET Domain Naming Context s Fig. 4 Naming Contexts in.net and 2000 Active Directories. 11

12 Schema and Configuration Some directory service data are related to the whole forest and are kept inside the AD in special global partitions, i.e. Schema and Configuration. The Schema partition contains a definition of the classes and attributes that can exist within the forest and is unique to the directory. For efficiency purposes, there are copies of the Schema partition on each forest DC. Even the directory architecture, its topology (see Section 3.3.4) and all other structural data must be accessible at the forest level. These data are located in the Configuration partition, they must obviously be the same throughout the directory and be easily available; for this reason there is a copy of the Configuration partition on every DC (see Fig.4). Note: Even if there is a Schema partition on every forest DC, only one of them is writeable, the others are just read-only copies. From a functional point of view, all DCs are identical, but the one holding the writeable copy of the Schema partition plays a unique role within the forest, called Schema Master Role (one of AD s five FSMO roles, see for further information). If necessary, for instance if the machine running the DC Schema Master fails, this role must be moved to another DC of the forest. If the transfer cannot be completed, for example if the DC with the Schema Master Role is not available, then it must be seized. Transfer of the Schema Master Role is carried out with the Schema Management snap-in (Microsoft Management Console) or with the command line tool ntdsutil.exe (see Appendix). Forests and Trees Windows.NET and 2000 domains can be grouped into trees and forests. The directory is structured like a tree of domains that collect Naming Contexts containing Active Directory data; each domain can include one or more DCs (replica DCs). From a system engineer s point of view, a tree is a collection of domains in two-way transitive trust, consequently the attention is focused on authentication and extension of the domain s physical boundaries 8. However this topology has also a specific meaning as far as the LDAP is concerned: identification of a directory object is related to its position inside the tree and this dictates how to create a correct LDAP string for accessing and managing directory objects. 8 Relationships between domains are particularly important when (AD object) replication costs are calculated. See [3] for cost computation. 12

13 Naming Context Naming Context Naming Context isqre.net Naming Context Naming Context central.isqre.net Naming Context Naming Context Naming Context Naming Context Naming Context Naming Context Naming Context london.central.isqre.net milan.central.isqre.net Fig. 5 Domain trees and Naming Context. Container and Leaf Objects At a high level, AD data are represented by means of an object orientation. Some objects are leaf, others are container (objects that can contain other objects). Containers are logical binders that can be used to further subdivide a partition s content. An OU is a specialized container, it has an administrative role and is used to identify a domain zone that needs to be manipulated coherently. For instance, policies and DACLs (Discretionary Access Control Lists) can be applied to an OU in order to manage some domain objects according to administration s needs. Policies will not be discussed here, for further information please refer to [1] and Note: A leaf object can become a container by writing its class name in the posssuperior attribute of another class (see Section Containment Relationships) 9. 9 Apart from OU s, many additional objects are containers; even User objects can, surprisingly enough, be containers. 13

14 Naming Contexts Objects Leaf Objects Naming Context Objects Naming Context Leaf Objects dc.domain.root Domain NC... Container Object Container Object... Fig. 6 Domain Controllers, Naming Contexts, Containers and Objects. Distinguished Name Domain Controllers are therefore a network of servers, or better a set of LDAP servers that store leaf and container objects, partitioned in Naming Contexts. AD objects are clearly identifiable in the directory according to a syntax that requires a precise specification of the object s position in the directory tree. LDAP syntax identifies a directory object by means of a vector called Distinguished Name (DN). The unambiguousness of an object s DN is guaranteed by the fact that, in a container, its name must be unique; similarly, Naming Context and DC names within the forest. A Distinguished Name usually has this syntax or CN=<value>,CN=<value>,DC=<value>,DC=<value> CN=<value>,OU=<value>,DC=<value>,DC=<value> or other similar ones according to its naming attributes 10. The administrator object (user class) located in the management OU (organizationalunit class) in the Domain partition of the milan.central.isqre.net domain will have the following Distinguished Name: 10 A class s name attribute is defined in the Schema by the meta-attribute rdnattid. 14

15 CN=administrator,OU=management,DC=milan,DC=central,DC=isqre,DC=net while the Configuration and Schema partitions of the isqre.net forest will have the following Distinguished Names: CN=configuration,DC=isqre,DC=net CN=schema,CN=configuration,DC=isqre,DC=net Note: Since Schema and Configuration are partitions that are identifiable at forest level (see Schema and Configuration), these two partitions Distinguished Names have the following syntax: CN=schema,CN=configuration,<Root_Domain_DN> CN=configuration,<Root_Domain_DN> where <Root_Domain_DN> corresponds to the Distinguished Name of the first domain created in the forest. This value can be found in the rootdomainnamingcontext attribute of the RootDSE object (see Section 3.4.2). If you want to access the Schema or Configuration copy of a specific DC, you must follow this syntax: LDAP://<ServerName> 11 [:<port>] 12 /CN=schema,CN=configuration,<Root_Domain_DN> For instance: LDAP://dc:389/CN=schema,CN=configuration,DC=isqre,DC=net or LDAP://dc/CN=schema,CN=configuration,DC=isqre,DC=net Relative Distinguished Names The first element on the left of a Distinguished Name is usually called Relative Distinguished Name (RDN). A user called alex created in the students OU of the isqre.net domain will have the following DN: CN=alex,OU=students,DC=isqre,DC=net and the following RDN CN=alex. Two identical RDNs cannot exist within the same container, but there can be objects with the same RDN, if they belong to different containers (in this case they have different DNs). Note: Users and computers that share the same domain cannot have identical logon names, even if they were created in different containers, because they cannot have identical User Principal Names or Downlevel Names (samaccountname). 11 <ServerName> can be a netbios name, a DNS name or an IP address. 12 The default port used by LDAP servers is

16 GUID Since AD objects can be moved from one container to another and from one Domain to another or can be simply renamed, unambiguous recognition of the objects located in the AD namespace is essential. To this purpose, each AD object is assigned a 128- bit unique number called GUID (Globally Unique Identifier), defined in the objectguid attribute, which will guarantee the object s consistently unambiguous identity. Summary What we described up to this point is a network of DCs, in a tree topology, storing a set of directory partitions containing objects that can be identified through their Distinguished Names or GUIDs. Later on we will see how these elements contribute to the directory s architectural structure and how the directory s logical representation maps the physical one AD, DNS and AD References What holds the directory elements together (DCs, partitions and objects) are DNS references on the outside (network location) and AD references on the inside (directory architecture). There are three kinds of AD references: cross references, continuation references and superior references. DNS, cross references and continuation references play a major role in the AD s relational structure and will be analyzed in depth later on Relationship Between Active Directories and DNS. The first step for an AD user who wants to interact with the directory is to contact a service with an AD access point. First of all one must find the IP address of a DC (LDAP server) and create a communication connection. To this purpose, their symbolic names, that must conform to RFC 2136, 2052, 1996 specifications, are published on a DNS. These RFCs define new characteristics for the DNS: RFC 2136: dynamic updates are introduced. This allows the DNS user to carry out a dynamic update of the DNS records without intervention by the administrator. RFC 2052: service location resource records (SRV RR) are introduced. This is a new kind of DNS record that allows definition of the parameters that cannot be defined with normal host records (AA). RFC 1996: a new kind of transaction, called dns notify, is introduced. This deals with sending new or modified data in a DNS zone. This way a DNS server can inform its partners that a change has occurred in its zone. While dns notify and dynamic update are not essential (but useful) to the operations of.net and 2000 domains, SRV RR are absolutely necessary, since DCs are published in DNSs as LDAP servers by using these kinds of records 13. SRV RR records not only allow the user to define the DNS name of a machine that provides a service (AA, CN records already do that), but also to supply three additional values: service priority (<priority>), weight (<weight>) and port (<port>). Priorities specify which endpoint 13 DC s usually exhibit also Kerberos services for authentication: also these services are shown by the DNS by means of the SRV RR records. For further information on Kerberos services please see specialized literature. 16

17 (IP address) should be chosen among those providing identical services (lower values correspond to a higher priority); weights specify which service to use with the same priority (the highest value is preferred); ports specify the IP port number the service is listening on. An SRV RR entry has the following syntax (square brackets are part of the phrase and do not refer to optional values): <name_of_service>, <type of record>, <[priority]> <[weight]> <[port]>, <host_dns_name> For example a DC is published on DNS zones/domains in an SRV record as follows: _ldap, SRV, [0][100][386], dc.isqre.net When a server is promoted to DC, i.e. when the AD is being installed on a particular server, many records of this kind are published in specific DNS zones (domains). In case a DNS conforming to RFC 2136, 2052 specifications were not available at the time of an AD installation, these zones will be saved in the netlogon.dns file (%systemroot%\system32\config) and should be inserted in the DNS later on. These DNS zones, created to help AD s operation, are easily recognizable, because they are identified by the prefix _ (underscore), as shown in Figure 7. Fig. 7 The _tcp.defaul-dirst-site-name._site._dc._msdc.isqre.net DNS zone contains two SRV- RR record entries (on the right) that identify the LDAP and kerberos servers of the isqre.net domain. Thanks to the publication of the forest DCs on the DNS - or better, thanks to the LDAP services that show the directory s partitions - and through the Distinguished Names, the object within the AD can be retrieved. 17

18 CN=< >,, OU=< >, DC=<subdomain>,DC=<domain>,DC=<root> Object identification DNS zone identification Table 3. The DC= elements of the Distinguished Name (DN) can identify the DNS zone where the LDAP server name that contains a directory partition, is stored; they are therefore related to connection issues and to the AD s physical architecture. the CN= and the OU= components and, generally speaking, the naming attributes that differ from DC= are used to identify (container or leaf) objects in the current partition, allowing their retrieval (see Figure 8). Fig. 8 Connection request to an AD object by means of a Distinguished Name AD References Considering this structure, the local Naming Contexts can be accessed once a DC has been located. In any case the user must be able to retrieve any partition from the whole directory, i.e. any Naming Context located within the domains forest (or outside, i.e. in a separate forest or in a non-microsoft LDAP server). To this purpose there must be a reference mechanism tied to all the Naming Contexts; these references are created with cross reference objects and referral and continuation messages. Cross Reference In the Configuration Naming Context there is the Partitions container, where all the cross reference objects are listed (crossref class). Cross references hold the directory together: they are used to obtain information regarding the placement of directory partitions located on other DCs. On every DC, within the Partitions container, there is a cross reference object for each of the forest s domains and for every other referred 18

19 partition. The content of the Partitions container represents the knowledge of AD about all directory partitions. Each DC can draw this knowledge from the local copy of the Configuration. Among the crossref object attributes the following are of special interest: cn: the name (Relative Distinguished Name) of the specific cross reference object ncname: the DN (Distinguished Name) of the referred partition (e.g. DC=DomainDnsZones,DC=isqre,DC=net) dnsroot: the DNS name of the zone where the server holding the referred partition is located. msds-nc-replica-locations (.NET): the Distinguished Name that identifies the DC s DSA (Directory Service Agent, see Section 3.7.1), where the ADP partition must be copied (e.g. CN=NTDSsettings,CN=dc1,CN=Servers,CN=Default-First-Site- Name,CN=Sites,CN=Configuration,DC=isqre,DC=net). ADP partitions are replicated only on DCs that are specifically listed in this attribute. Note: crossref objects can be viewed with adsvw.exe (see page 29) and by connecting to the LDAP://cn=partitions,cn=configuration,<Root_Domain_DN> object. Using the Knowledge When a user carries out a query in AD, the LDAP sends a SearchRequest(3) message to the DC (see Section 3.2.2). Depending on the query, different kinds of response messages are generated: Response; Referral; Continuation. Response is an LDAP SearchResultEntry(4) 14 message containing a list of Distinguished Names and attributes that satisfy the request. On the other hand, Referral and Continuation are messages containing references useful to carry the search on. These references are built up on the knowledge that the DC has about the AD. In the following two sections the last two messages will be analyzed in depth. Referrals When a client asks for information, with base scope (see 3.2), that is not included in the partitions located on the current DC, an error message called referral (RFC 2251) is returned. A referral is an LdapResult structure with a ResultCode 10 in a SearchResultDone(5) 15 message. The LdapResult structure scheme is as follows: LdapResult ResultCode ; /* integer; specifies the SearchRequest s result type */ matcheddn; /* optional; it depends on the result code */ errormessage; /* a description string */ 14 SearchResponse(4) in Network Monitor 15 SearchResponse(5) in Network Monitor 19

20 referral; /* optional; sequence of LDAPURL */ Only if the ResultCode value is 10 the LdapResult.referral field is present. This field contains one or more references as LDAP URL necessary to continue the search on other servers. A LDAP URL is a string: LDAP://[Host [ ":" Port ]]/[DN] host specifies the server s DNS name (or the IP address) where the search can be carried on, port is the IP port number (389 by default) and DN specifies the Distinguished Name of the searched object. If the user activated the chase referrals option ( follow the information given by the referrals ) in the search parameter list, the search continues on the servers listed in the referral field. Continuation Reference When a search with one level or subtree scope in the referred Naming Context is finished, if the AD service determines that there are subordinate partitions, it returns a continuation reference signal to the client; continuation reference is a SearchResultReference (19) 16 message containing one or more LDAP URLs, that could be represented as follows: SearchResultReference LDAP://<hostnameT>/<DistinguishedNameA> LDAP://<hostnameS>/<DistinguishedNameB>. Again, in this case, LDAP URLs specify where the search can be continued. Following is the example of a continuation reference message that was captured with Network Monitor. In this example, a search for domain admins objects were performed with isqre.net as search base, subtree as scope and with a specific set of attributes in the attribute description list. As shown in Figure 9, LDAP generates a SearchRequest(3) message. First the DC returns a SearchResponse(4) message containing the elements found in the original Naming Context that satisfy the request (Fig. 10), then a continuation reference (Fig.11) listing the LDAP URLs follows. These references indicate the subordinate Naming Contexts in which the search can be carried out; any other search can generate other continuation references until subordinate Naming Contexts exist. 16 SearchResponse(19) in Network Monitor 20

21 . Fig. 9 A SearchRequest(3) captured with Network Monitor. Please note the Base Object, Scope, Filter parameters and the Attribute description list. Fig. 10 A SearchResponse(4). The server returns the required objects listed in the original Naming Context. Fig. 11 A SearchResponse(19). The server generates a continuation message. 21

22 3.4 Object-oriented AD AD describes all information it contains at a high level as objects, at a low level as table lines which columns represent objects attributes. Fig. 12 AD objects represented in a table. This metaphor is used to define both information (objects and attributes) and metainformation (classes of objects and attributes), similarly to what happens in relational databases, where tables are used to describe the formal structure of other tables. Objects that describe meta-information (class and attribute schemes) are grouped in a single partition called Schema, which elements are true objects with modifiable attributes. Since object definitions can be modified, the Schema is extensible Class definition Schema Object Schema is an object with meta-descriptive functions. By examining its structure 17 we can see that the dmd class (the Schema partition is one of the dmd class instances) can contain two kinds of objects, in particular: attributeschema objects: They define the attribute schemas that make up the classes (meta-information). Object s attributes are defined by instances of these classes. classschema objects: They define class schemas (meta-information) of which objects are instances. These objects are used to define classes attributes and classes formal structure. They also define instantiation rules (if an object can be created and to what type of categories his class belongs to; see Class Categories ) and the inheritance hierarchy, which will be shown later on. The fields defined in the Schema table will be called meta-attributes, they are used to describe some of the relationships mentioned previously. 17 See page 27, Analyzing Objects and Partitions. 22

23 Meta-attributes Fig. 13 The Schema as a table; headings are meta-attributes. Attributes Active Directory s attributes are what are usually called object attributes, their characteristics are described in the Schema in an abstract way and they are associated with objects by means of specific attributes that belong to the objects (see the next Section Creating a class). Here are some relevant characteristics: Mandatory or Optional: Class attributes can be mandatory or optional (mustcontain, systemmustcontain and maycontain, systemmaycontain, see following Section). Mandatory attribute values must be specified when the objects are instantiated. Multivalued or Singlevalued: Some attributes are single-valued, while others are multi-valued. This feature is defined in the issinglevalued meta-attribute (Boolean). Indexing: For performance reasons, some attributes are indexed so that the required elements can be located more quickly; this makes sense for the most widely used attributes (like distinguishedname, objectcategory, etc.). This characteristic can be set with the searchflags attribute (a bitmask) by setting its first bit. Syntax: Syntaxes define the types of values that can be assigned to attributes. Syntaxes are primitive types that are not defined in the Schema, but are coded in Active Directory. They are connected with the attributes by means of their OID numbers (see RFC 2252), therefore, while new classes and attributes can be defined, new types of AD syntaxes cannot. The meta-attribute defining an attribute s syntax is attributesyntax (standard X.500), while omsyntax and OMObjectClass attributes define syntaxes according to other standards (XOM/X400). Creating a Class The Schema meta-attributes are used to describe: a unique class identifier, a name, pointers to containers for nesting, pointers to superclasses for derivations, derivative types and attributes a class must or may have when it is derived (or that an instantiated object must possess). Here is a schematic (concise) representation of a class: ObjectClassDescription 23

24 Object Identifier; // Octect String Name; // (String) SubClassof; // Object Identifier; a de facto pointer PossibleSuperior// Object Identifier Derivative Type; // ( "Abstract" "Structural" "Auxiliary" "88") MustContain; // attributes list MayContain; // attributes list ClassSchema objects contained in the Schema describe of which attributes a class is formed by using four special meta-attributes: mustcontain maycontain systemmustcontain systemmaycontain MustContain attributes refer to mandatory attributes, MayContain attributes refer to optional ones (see Attribute Section above) and can be modified by the administrator; SystemMustContain and SystemMayContain play similar functions, but can be manipulated by the Directory System Agent only (see Section 3.7.1). All these attributes are multivalued. Fig. 14 How the Schema defines class attributes by means of its meta-attributes. 24

25 Containment Relationships As already pointed out, some objects are container objects, others are leaf objects. The following Schema meta-attributes are used to define by which classes other classes are contained: posssuperiors systemposssuperiors possibleinferiors All these attributes are multivalued. For every class the two posssuperiors and systemposssuperiors meta-attributes indicate what kind of object can contain one of its instances. In this case as well, the posssuperiors attribute can be modified by the administrator, while systemposssuperiors can be manipulated only by the DSA (Directory System Agent). Values of possibleinferiors attribute are calculated dynamically from those of posssuperiors and systemposssuperiors. Class Categories Classes belong to different categories. These categories define how classes are built and the rules that regulate their derivation. Below is a list of every category s characteristics: Structural (concrete classes): An object can be an instance of a Structural class only. A Structural class can be defined (derived) both from non-concrete classes, like Abstract and Auxiliary, and from other Structural classes. Abstract (non-concrete classes): Abstract classes are superclasses and they are used to define other Abstract classes as well as Auxiliary and Structural ones. These superclasses are used to build classes from an already existing model. Auxiliary (non-concrete classes): These classes are simple attribute collections and they work similarly to object programming interfaces. They can be derived from other Auxiliary classes or from other Abstract classes. In AD s 2000 version, only classes can inherit attributes from Auxiliary classes (static linking), in.net even objects can (dynamic linking, see Section 4.2.5). 88 (concrete classes): This category is present for compatibility with X.500. The category a class belongs to is defined in the Schema s objectclasscategory meta-attribute and is identified by number: 0 = 88; 1 = Structural; 2 = Abstract; 3 = Auxiliary. 25

26 Class Derivation Classes can be derived from other classes. Some meta-attributes define these relationships, namely: subclassof attribute identifies the class derivation hierarchy. This attribute is single-valued, so that a class can be derived only from another specific class, there is no multiple inheritance. With auxiliaryclass (a top class attribute) and systemauxiliaryclass (a meta-attribute) attributes, we can realize a form of multiple inheritance by defining from which Auxiliary classes we want the class to inherit further attributes. Note: AuxiliaryClass and systemauxiliaryclass attributes are multivalued and they allow listing of zero or more classes. Also in this case, the first attribute can be modified by the administrator, while the second can be modified by the Directory System Agent only. Instantiating a Class AD objects are instances of a Structural class, which is derivated from either Structural, Abstract or Auxiliary classes. Schema defines what classes an object is derived from and consequently which classes and superclasses the object must inherit his set of attributes from. As previously mentioned, inheritance is defined by the subclassof attribute; systemauxiliaryclass and AuxiliaryClass attributes define the Auxiliary classes from which further attributes are derived. SystemPossSuperiors and posssuperiors attributes indicate where a class can be instanced. Furthermore, all AD objects are class instances that come directly or indirectly from the top class, the Active Directory root class which contains the definition of attributes that objects must posses, like objectguid, DN, objectcategory attributes and so on (for further information, see MustContain, systemmustcontain, MayContain, systemmaycontain attributes for this class). Note: Instantiated objects keep track of classes they inherit from in the objectclass multivalued attribute. Following, a graphic representation of how the user class is defined by means of other classes 18 using inheritance mechanisms; users and computers listed in AD are instances of this class. 18 For reasons of space, this is only a partial representation. For further information, please analyze the Schema with the given tools. 26

27 Fig. 15 Inheritance hierarchy and dependences of the User class. Analyzing Objects and Partitions When interacting with AD, even if it is in a programmatic way, it is sometimes advisable to check the properties of the objects one intends to use. Two useful tools for AD objects and partitions analysis, Schema included, are csvde.exe (located in system32 folder) and adsvw.exe (platform SDK). Note: If you want to have an overview of the values and attributes of a partition or of a certain number of objects, we suggest using csvde by importing the output file into Excel. This is particularly useful, if you want to carry out a detailed analysis of the 27

28 Naming Context contents by executing comparisons and checks. For example, a file containing all the Schema objects can be created as follows: csvde -f schema.csv -d cn=schema,cn=configuration,dc=isqre,dc=net -r (objectclass=*) where dc=isqre,dc=net represents the rootdomainnamingcontext (see Section RootDSE) of the forest in Figure 5. The csvde tool was already mentioned in Section 3.2, so we will not examine it any further. Adsvw.exe is a graphic interface tool included in the SDK Platform. There are other similar instruments for analyzing AD (see Appendix), in any case, Adsvw.exe allows a more detailed view of the AD objects properties and the use of other available ADSI providers, that is why we recommend it. Connection with AD is possible by means of adsvw.exe, by accessing the file\new menu and choosing the ObjectViewer option. Then will be displayed a form (Fig. 16) requesting the DN of the object you want to connect to (Section provides some examples of connection strings). Fig. 16 Binding to the domain partition of the isqre.net domain via LDAP provider. Since AD requires authentication, a security principal must be specified if the Use OpenObject and Use Encrypt options are unchecked and the Open As and Password authentication fields are blank. In this case, the credentials inherited from the parent process are used, i.e. those belonging to the currently logged on user. This is a quick procedure if you have the necessary rights on the system. Once the binding is completed, the object specified in the Ads path field appears. In the left hand panel, the object tree can possibly be expanded and its contents examined. The right hand panel shows a description of the selected object on the left and a menu for accessing its properties. 28

29 Fig. 17 Adsvw.exe connected with the dc=isqre,dc=net domain shows a section of the tree and some of the alex object s properties (User class). If you want to view the Schema partition contents, this is a possible connection string: LDAP://cn=schema,cn=configuration,dc=isqre,dc=net where dc=isqre,dc=net represents the rootdomainnamingcontext (see Section RootDSE) Objects Providing Entry Point Information Some objects are used to retrieve preliminary information related to the domain or the forest the user is in. These objects are necessary to free the programmer from a particular domain and provide a first access that will then lead to further references to domain or forest objects. ADS By employing ADS container, you can find out which ADSI providers are available within the working environment. ADS container implements the IADsNamespaces interface and provides information related to the dynamically available ADSI providers. Thanks to that it is possible to write programs that work differently depending on existing providers. 29

30 Note: Contents of the ADS container can be viewed in adsvw.exe simply by writing ADS: in the ADs Path. RootDSE The RootDSE object has been introduced in LDAPv3. It is a virtual object that is not defined within the Schema, does not contain inferiors and has no possible superiors. It collects attributes that include key information related to the domain and the specific DC being accessed. A RootDSE is not a root per se, but a uniform logical entry point, so that code can be independent of a particular Domain. Following is a list of RootDSE s most important properties, some of which have been already mentioned in the previous sections. RootDSE: - defaultnamingcontext: It retains the DN of the accessed domain. - schemanamingcontext: It retains the DN of the domain s forest Schema; this partition is replicated on all DCs. - configurationnamingcontext: It retains the DN of the Configuration partition. This partition contains information related to the forest structure that is divided on to three containers: sites, services and partitions (which contains cross references, see Section 3.3.4). - rootdomainnamingcontext: It retains the DN of the first domain installed in the forest. - namingcontexts (multivalued): It contains the DNs of all partitions that were replicated on this DC, including the DNs of any Application Directory Partitions. - servername: It retains the DN of the local domain controller. Note: One can connect with RootDSE via AdsVw.exe and list its contents by using the following AdsPath: LDAP://RootDSE Global Catalog In order to make AD-object retrieval more time effective, a support service, Global Catalog (GC), has been introduced in the forest. Global Catalog behaves like a real AD parallel agent that integrates and simplifies its operation. GC s purpose is to collect the forest objects key attributes. Some information can be obtained directly by asking the GC, before involving AD, thus avoiding an examination of the whole directory by following continuation references and referrals. For efficiency s sake, the GC only contains a partial data replication, i.e. only those AD data and attributes that have been marked in the Schema by setting to TRUE their ismemberofpartialattributeset meta-attribute. At least one forest DC is designated as GC server (by default the first DC installed in the forest), but this service may also be activated on other DCs. Even if a GC could 30

31 theoretically be put on each forest DC, this is not always advisable, since GC s data are many and prone to replication. An excessive amount of GCs could lead to inefficient use of the network s resources. Designating a GC server for each site, i.e. for each tightly interconnected zone (for further information see would reduce the number of inter-site queries required to obtain forest-level attributes and the amount of network traffic towards narrowband zones. In this case, the GC would play the role of proxy for the forest data. Fig. 18 The Global Catalog collects attributes (and objects), coming from the whole forest, for which the value of the ismemberofpartialattributeset meta-attribute is set to TRUE. It should be added that authentication can fail if the GC is not active or cannot be reached. Some special domain groups can be viewed at the forest level and are called Universal Groups. Universal Group membership is included in the GC for scope reasons: during authentication the operating system must query the GC to check if the user belongs to a Universal Group (and consequently build the correct token). This function can be disabled, if necessary, by creating the Hkey_Local_Machine\SystemCurrentControlSet\Control\Lsa\IgnoreGCFailures key in the register, but this rarely makes sense, because this involves missing the opportunity to obtain user memberships in the Universal Groups. The Global Catalog s contents can by viewed by using the GC: provider (by applying a syntax similar to LDAP: ), for instance: GC://dc=isqre,dc=net 31

32 Global Catalog is an LDAP service available on the IP port 3268 (instead of the port 389); you can connect to the GC by explicitly indicating the IP port within an LDAP URL: LDAP://<servername>:3268/dc=isqre,dc=net The Global Catalog s contents can also be obtained via csvde; indeed, a binding port can be defined with the csvde switch t. In the following example the csvde tool connects with the GC: provider by using the 3268 port and writes its contents into the gc.csv file. csvde -f gc.csv -t d dc=isqre,dc=net -r (objectclass=*) Note: objectclass is a top class mandatory attribute, the (objectclass=*) expression returns all the contained objects. Note that the same hierarchy of the AD forest is recreated within the GC. 3.5 AD Replication Some directory partitions are replicated on different forest DCs, in particular: Schema and Configuration partitions are replicated on all forest DCs. Domain partitions are replicated on all DCs within the same domain (for fault tolerance a domain may have more than one DC). ADP partitions are replicated on the DCs that are explicitly indicated in their cross references (see 3.3.4, Cross Reference). Any changes to AD data must be propagated to the appropriate replica DCs. Furthermore, as we already mentioned, the GC collects and publishes copies of data coming from the whole forest. Within the forest, a lot of data must then be replicated from one DC to another; for this reason, a secure, consistent and effective replication mechanism must be available. 32

33 Fig. 19 The Administrator object (user class) and some of its attributes used for replication Replication Granularity Every time an object is modified, the variation must be propagated on the replica DCs in order to keep the view of the objects state consistent within the forest. AD s level of replication granularity reaches the attribute. DSA (Directory Service Agent) is able to determine precisely which object fields were modified, and limits replication to the changes made (modified attributes), avoiding unnecessary transfers of big amounts of data Update Sequence Numbers (USN) Every Domain Controller in the domain keeps a local counter called Update Sequence Number (USN). When an object s property is somehow modified, the USN increases and its new value is copied in a specific field of the modified attribute. For every object in AD there are two USN fields: the first (Originating USN) contains the number related to the DC that last created or modified the attribute, while the second (Local USN) contains the local USN. Among the various attribute properties there is also the Originating DC field containing the GUID of the last DC that created or modified the attribute (see Fig. 19). When replicating AD s data, one must first determine what really has to be replicated. This operation is relatively simple and has been designed to limit network traffic to a minimum. Every DC memorizes the value of the last USNs received by the other replication DCs in a special array (called Up-to-Dateness Vector), every vector element corresponds to a specific domain DC. When carrying out a replication, these USNs (called High-Watermark) are sent back to their original DCs, which compare these values with their present USN. Based on this comparison, every DC is able to create a list of the data that need to be replicated on a specific DC. 33

34 3.5.3 Conflict Resolution: Stamps During replication two or more DCs may try to replicate changes made to the same attribute simultaneously, thus generating a conflict. This can be resolved by comparing attribute stamps, i.e. the following three values: Version : a counter. Every time the attribute is modified the Version value is increased by 1. TimeStamp : a time variable. It memorizes the exact time of the attribute s modification. Originating DC : an octect string. It contains the GUID which identifies the last DC that modified the attribute. In case of conflict, every field of the two attribute stamps is compared: the attribute with the biggest number of Version prevails. If two attributes were to have the same number of Version, then the value of the TimeStamp field would be compared, i.e. the time when the attribute changes were carried out. The data that was modified last, wins. If these two evaluations fail to produce a solution to the conflict, the values of the Originating DC field are compared: the highest GUID prevails; this is comparable to tossing a coin, since GUIDs that are assigned to the DCs are randomly generated. Note: Please remember that as far as the TimeStamp value is concerned, the time of creation or modification of an object or attribute refers to the GMT/UTC (Greenwich Mean Time/Universal Time), a very specific time zone also known as Zulu Time. This way, the DCs that belong to different time zones have a common ground on which time comparisons can be carried out. The Local USN, Originating DC, Originating USN, Originating Time (TimeStamp) and Version fields can be called up by using the repadmin /showmeta <DN> command. For instance: repadmin /showmeta cn=dc1,ou=domain controllers,dc=isqre,dc=net 3.6 Active Directory Represents the Domain Even if Active Directory was created as a directory service, or better, as one of its specific implementations, we need to remember that Microsoft developed this service with the specific purpose to represent domains. This is not in conflict with its directory service nature, but it is in fact appropriate and has specific advantages Domain as a Concept In a lot of professional literature, domains are defined as a collection of machines, a collection of computers. This definition is not completely incorrect, but it is also not complete or satisfactory; for instance, it is not sufficient to distinguish between domain and workgroup (both terms are present in Microsoft terminology). The concept of domain should therefore be defined more closely, before being applied, since it has to do with AD s operation. In general, we can say that a domain is a coherent set of services that are shared by several users. On one hand, we are talking about a list of objects, procedures and functions that share a coherent vision; on the other hand, we are dealing with a set of 34

35 real or virtual users (other services) that have major or minor rights to access this set of resources. A domain s objective is to define the exact application boundaries of the functions it offers, discriminating the access of real/virtual users in a controlled way as to guarantee data and function management, security (privacy) and therefore consistency and reliability of the service itself. Domains could also be considered a way to extend the security and operational boundaries defined by an individual machine and prolong it beyond the physical limits set by its hardware components. In fact, it is this second feature, with its real practical value, that allowed the concept of domain to spread within the Microsoft environment; therefore the definition of Microsoft domains encompasses both these definitions. Active Directory is quite suited to represent a domain, since it offers a service that is able to represent and give technical support to this abstract concept Security, Domains and Multiusers The concept of Microsoft domain closely depends on the concept of security. In fact, it originates from the need to manage the behavior of several users, who share the same logic and operational environment. The words used to define such concept are multiuser environment. In a multiuser environment, different individuals may try to access resources simultaneously. The concept of simultaneous should be understood in a very broad sense: in some computer systems, for instance, the existence of static data may make the access of two individuals to the same resource virtually simultaneous, even if it is not timely coincident NT Security NT operating systems are multiprocess, multithreaded, preemptive, round robin and managed with a priority queue (for more information see [10] and [15]). NT lets users and programmers access and manage system resources through handles (indexes of a table of system objects pointers). Every NT process runs within the security context of a specific real or virtual 19 user of the system. Every time a process accesses one of the system s objects, i.e. one of the internal resources, a kernel component (the object manager) asks the security reference monitor to check if the user who is associated with the process is authorized to use that resource Solving the Multiuser Problem: User Identification Security is a prerequisite to the operation of the NT operating system. Stand alone PCs as well as Domain Controllers must be able to verify the identity of the user who wants to access the system in a safe and unambiguous way before allowing access to any of the resources. There are several ways to verify a real or virtual user s identity, but one of the most common ones is the shared secret method: the user is asked for his name and password that is, in general terms, only known to the system and the user; in multidomain systems, the user s domain must also be indicated. In Windows.NET and 2000 the authentication operation is mandatory and is carried out before the user is able to act on the system. 19 For example, NT_LOCAL_AUTHORITY or SYSTEM are virtual users, in whose context system processes, subsystems and other services run. 35

36 During the authentication process, Winlogon process asks the local security authority (the lsass.exe subsystem) to check if the given name and password are located in a security database. If operation succeeds, the local security authority returns a ticket. The ticket contains a synthetic, but exhaustive description of the user from a security point of view: his SID, his user rights and the groups he belongs to; synthetically the user s security context. The ticket is issued to the user only if the authentication was successful. The SID (Security Identifier) is a globally unique identifier: it is generated at the time of the user s creation and is associated to him statically. If a user is deleted and recreated using the same username and password, his SID will be recreated: since the user is identified by his SID, from the system s point of view, his identity will therefore be different. The SID of the user currently logged on can be viewed programmatically or simply by using regedit (Fig. 20). Fig. 20 The administrator s SID as seen in the user register. Note: Tickets are static data stored in a volatile memory (RAM). This means that for any variation in the user s rights, any change in his group membership or any variation to the definition of his security context to be effective, the user is required to repeat the authentication process (usually logoff followed by logon). Recalling the abstract definition of domain as a coherent set of services and resources that several real or virtual users have a specific right to access, the service available is the set of machines and resources that the system provides at an architectural level (Kernel objects, Files, Inter Process Communication services, Communication Ports, etc.) and via network (Firewalls, Shares, File Servers, Databases, etc.), to which only authorized users and machines (the security principals) have permission to access to. Therefore, domains are defined on one hand by their security database content (who can access the domain), on the other hand by their resources (what sections of the domain may be used). Active Directory can store in addition to the security principals, i.e. the elements of the security database, objects and resources the user wants to access to. This is why, inside Active Directory, we find predefined objects, related to the domain s description and needed for its management, that map application domain objects like users, computers, groups, OUs, policies, etc. 36

37 3.7 Directory Services Directory services are the core operational engine of AD. Since AD stores security information, to safely execute authentication and authorization operations on its database (and therefore on its domain), it must operate in the Security Subsystem security context, the lsass.exe process (for further details, see [10]). The Security Subsystem, that runs in user mode, works in conjunction with the security reference monitor, a kernel component that authorizes processes to operate on resources supplied by the operating system Agents, DB Layer and ESE From an architectural point of view, directory services are made up of three overlapping layers: the Directory System Agent (DSA), the Database Layer and the Extensible Storage Engine (ESE). Fig. 21 The Directory Service Agent Each one of these three components plays different roles: the DSA (NTDSA.dll) creates relathonships between objects and their containment hierarchy by deducing if from tables and from the information provided by the underlying DB layer. The DSA uses different interfaces to show directory data: MAPI: Microsoft Outlook clients connect to the DSA (Directory System Agent) by using MAPI communication interfaces (RPC). SAM: Windows NT 4.0/3.51 clients use this interface to connect with the DSA. In mixed-mode domains, where Backup Domain Controllers are still available, they communicate with.net e 2000 DCs thanks to this interface. REPL: DSAs use this interface to replicate data from one DC to another; replication may happen via RPC or SMTP protocols (for further details, see 37

38 LDAP: Clients communicate with DSA by using the LDAP protocol; Active Directory supports LDAPv2 e LDAPv3 versions. The LDAP protocol may be used in a Microsoft environment via programming by LDAP API or ADSI (Active Directory Service Interfaces). The DB layer creates a table view starting from the information stored in the underlying layer. DB layer mainly uses two tables: the object table, that describes the set of objects stored in AD, and the link table, that shows their relationships. The Extensible Storage Engine (ESENT.dll) has access to the database s physical section. Data are stored in the NTDS.DIT file, i.e. the directory store. ESE uses ISAM (Indexed Sequential Access Method) technology to manage the physical support data. ESE supports indexing, multivalued attributes and, in order to guarantee consistency in read and write operation, it uses transactional writing methods. Transaction operations (not yet committed) and checkpoints (committed) are saved on two files: EDB.LOG and EDB.CHK respectively. Thanks to its features, ESE allows backup operations even if the AD service is running. EDB.LOG, EDB.CHK and other related files must be included in an AD backup for a proper operation. 4. Programming Even if there are several communication services supplied by the DSA, LDAP remains the principal way for programs to interact with AD. The LDAP API, (RFC 1823) are C programming libraries that provide methods for reading, inserting and deleting directory data. Microsoft makes these APIs available through a special implementation of COM interfaces, called Active Directory Service Interfaces (ADSI). Thanks to the mechanisms provided by the COM model (see [6]), ADSIs abstracts the LDAP APIs so that they become usable in a distributed and languageindependent way on COM platforms. This is why, in these environments, ADSIs can be used with C++, Visual Basic, several scripting languages (CScript, JScript, VBScript, etc.) and with C#; and in general with the most common.net languages (thanks to the existence of a COM wrapper on the.net platform). This paper includes examples created in C++ and in C#. C++ gives a better view of how COM interfaces are used (but it requires more programming); C# makes the programming more concise, because it hides the COM implementation and offers a programming model based on objects (with all the connected advantages). Later we will see how AD can be manipulated and analyzed with ADSI. Programming techniques for the mentioned languages will not be discussed, since knowledge of COM, CLR, C/C++ and C# is a prerequisite. 4.1 Connection with Active Directory In the first part of this section we will examine which mechanisms are used to connect with AD and how the published information can be read Binding Strings Two elements are necessary in order to have access to an AD object: a connection provider and the object s address in the directory service. The address must be 38

39 compatible with the chosen ADSI provider. Together these two elements make up what is called binding string or ADsPath. In the following table there are several connection strings for the same object. 1 LDAP://DC=isqre,DC=net 2 LDAP://dc1:389/DC=isqre,DC=net 3 LDAP://<GUID=91cc2709c91cc045b890ba4edd99fdcf> 4 GC://DC=isqre,DC=net 5 WinNT://isqre Tab. 4 List of different AdsPaths that identify the same object. As mentioned earlier, the object s address in the directory service is closely related to the chosen provider. From the list shown in the previous table, it is clear that different providers do not necessarily have addresses with a different syntax and that the same provider may support different addresses for connections with the same object. Here is a brief explanation about the providers and AdsPaths listed in Table 4. Note: Please remember that authentication is a prerequisite for an AD connection. In the examples listed in this paper, credentials of the current user are employed in a transparent way, although there are functions that make it possible to use different credentials. LDAP An AD connection can take place through LDAP: ; in Table 4 there are three different connection strings that use this provider. The first one allows a serverless connection: communication will happen with one of the Domain Controllers of the default domain, i.e. the one owning the security context of the thread that carried out the request. Otherwise (second string), the server and the connection port may be explicitly specified. In general, serverless connections are more advantageous: in this mode, if at least one DC is available, the call proceeds with the search of the required object. Specification of a particular Domain Controller allows explicit checks: a typical scenario involves diagnostic operations for checking the consistency of data located on different DCs. Another instance involves an application that executes successive and frequent reads and writes on the same object: also in this case, in order to avoid replication latency problems, having only one specific Domain Controller as a reference may be preferable. GUID The difference between the first two ADsPaths and the third one is represented by the identifier used to locate the object. With the first two ADSPaths, the LDAP: provider is told what the logical object address is, i.e. its Distinguished Name. With the third one, the object is requested through its GUID (Globally Unique Identifier). GUIDs are unique identifiers that are associated with the object at its creation. This kind of connection may only take place if the object s GUID value is known beforehand, and it is certainly not a particularly friendly operation. The advantage of using GUIDs resides in the fact that, once the value is known, a connection with the related object is possible even if the object was moved, renamed or deleted (if the tombstone period is not over). 39

40 GC and WinNT The last two connection strings shown in Table 4 are different from the previous ones because of the providers they each use: GC: and WinNT:. The GC: provider is employed to connect with the Global Catalog and its syntax is similar to the LDAP: provider binding strings one. The WinNT: provider (Windows NT Directory Service) was created to access some resources of the NT4 workstations and servers and their security database via ADSI. It is used to remotely modify the status of the available local resources, like printers, shares, services, and it enables access to the security database so that users and local groups can be added, removed or modified. This provider also executes the same operations in a Windows 2000/.NET/XP environment, thus carrying out local operations that the LDAP: provider does not implement. In the Appendix there are two programming examples of how to use ADSI on a WinNT: provider. The first one shows a simple implementation of remote service management, while the second one shows how to insert a group defined in Active Directory into one of the machine s local groups. In any case, we will not go into the analysis of this provider, because its relationship with Active Directory is only partial. For further information and detail see Rootdse In the connection strings we considered up to now, knowledge of the working environment, for instance the domain s name, has always been taken for granted. On the other hand, it is true that, for reasons of flexibility, a commercial or other application must run independently of its originating environment. In order to implement this feature, at the program start the user could be asked to provide all the necessary information (many analysis tools require the Distinguished Name of the working Domain Naming Context). Otherwise, the program could independently single out the main characteristics of the domain where it will be executed by accessing rootdse (see Section 3.4.2, RootDSE). Section illustrates access to rootdse via programming. Note: RootDSE localization is carried out by the DNS, which, as was already mentioned, is a service that is essential to Active Directory s correct operation. 4.2 Example Codes As mentioned in the list of prerequisites, knowledge of C++ and/or C# languages and COM technology fundamentals are taken for granted. Nevertheless, in order to make reading the examples easier, a little introduction should be made regarding the languages, the object classes and programming interfaces that will be used. C++ As previously noted, ADSI abstracts the LDAP APIs with COM technology, i.e. this way Active Directory s objects can be manipulated via interfaces, each of which contains (publishes) a subset of the operation that can be executed on the object it pertains to. Programming ADSI in C++ takes place at a lower level: the programmer must have good knowledge of COM technology, since he/she must deal with it personally, unlike what happens with other languages (e.g. Visual Basic and VBScript). For instance, COM libraries must be initialized before using any ADSI function or interface with the CoInitialize(NULL) call (as defined in the objbase.h file), and they 40

41 should be released at the end with the corresponding CoUninitialize() call. Every time an interface is to be used with a particular AD element, the interface name must be indicated by means of its Interface Identifier (IID_<InterfaceName>). When a COM object is no longer needed, the Release() function should be called in order to manage the memory correctly. Table 5 briefly lists the ADSI interfaces that will be used in our examples (for a more detailed list and for further detail, see Interface IADs IADsContainer IDirectoryObject IDirectorySearch IEnumVARIANT Table 5 Brief description It is supported by all objects and contains methods for reading and writing the object s attributes. It is supported by nodes with children and allows their creation, deletion, transfer and connection. It allows direct access to an object and is used in C++ to create new elements. Provides methods to carry out a search in the Directory. Facilitates listing of a collection of elements. C# In the.net environment, ADSI libraries can be used thanks to specific framework classes that are kept in the System.DirectoryService namespace. Two of the most significant classes in this library are DirectoryEntry and DirectorySearches. The first one is used to execute operations on the directory service element it refers to, like reading and modifying attributes and create or delete children nodes (if the element is a container). The second one contains properties and methods to set the parameters needed to carry out a search. Around these two classes there are many more, e.g. those used to manage object collections, that make programming in.net extremely intuitive and fast. Moreover, in a.net environment, in order to efficiently manage the memory, the system should be informed via the specific Dispose() call when an AD object is no longer in use. Dispose() releases unmanaged resources, which are not directly managed by the CLR Garbage Collector..NET framework libraries hide to the programmer the details of COM and ADSI technologies. In the.net environment native ADSI interfaces can be used by importing the activeds.tlb 20 library and by executing an object cast, as shown in the WinNT_1.CS and WinNT_2.CS examples in the Appendix. Note: The examples in this paper need the ADSI libraries listed in Table 6. Language Libraries Location C++ activeds.lib, adsiid.lib MS Platform SDK, ADSI 2.5 SDK C# System.DirectoryServices.dll MS.NET Framework SDK Table 6 20 This library can be imported in Visual Studio.NET by executing the following procedure: Access the Solution Explorer window, execute add reference in the reference folder (right-click), chose Active DS Type Library from the COM tab. 41

42 4.2.1 Rootdse The following two code examples show how rootdse can be accessed in C++ and C#. This is a typical operation and it will be performed also in the following examples. CODE01.CPP #include <objbase.h> //CoInitialize and CoUninitialize declaration #include <activeds.h> //ADSIs #include <stdio.h> void wmain() HRESULT hr = NULL; IADs *prootdse; VARIANT var; WCHAR * sdomainpath; int size; //initialize COM library hr = CoInitialize(NULL); if (FAILED(hr)) wprintf(l"coinitialize() error: %x\n", hr); return; //bind to rootdse object, using an IADs interface hr = ADsGetObject(L"LDAP://rootDSE",IID_IADs,(void**)&pRootDSE); if (FAILED(hr)) wprintf(l"adsgetobject error: %x\n", hr); CoUninitialize(); return ; VariantInit(&var); //get local Domain NC Distinguished Name hr = prootdse->get(l"defaultnamingcontext",&var); //IADs object is no more needed prootdse->release(); if (FAILED(hr)) wprintf(l"iads::get error: %x\n", hr); CoUninitialize(); return ; //print on standard output the local Domain DN wprintf(l"default Naming Context: %s\n", var.bstrval); size = (int)wcslen(l"ldap://") + wcslen(var.bstrval) + 1; sdomainpath = (WCHAR*) malloc(size*sizeof(wchar)); //build the binding string to the local Domain NC swprintf(sdomainpath,l"ldap://%s\0",var.bstrval); VariantClear(&var); //print an ADsPath of the local Domain Partition wprintf(l"default Naming Context ADsPath: %s\n",sdomainpath); 42

43 //free COM library CoUninitialize(); return ; END CODE01.CPP CODE01.CS using System; using System.DirectoryServices; //.NET classes for ADSI class RootDSEApp static void Main(string[] args) //bind to rootdse object DirectoryEntry rootdse = new DirectoryEntry("LDAP://rootdse"); //get local Domain NC Distinguished Name string domaindn = (string)rootdse.properties["defaultnamingcontext"][0]; //print on standard output the local Domain DN Console.WriteLine("Default Naming Context: 0",domainDN); //build the binding string to the local Domain NC string domainadspath = "LDAP://" + domaindn; //print ADsPath of the local Domain Partition Console.WriteLine("Default Naming Context ADsPath: 0",domainADsPath); END CODE01.CS //Release DirectoryEntry object resources rootdse.dispose(); Container Listing Let s see now how we can connect to a directory node and list the elements it contains. The first example is in C++, the second one is in C#. CODE02.CPP #include <objbase.h> //CoInitialize and CoUninitialize declaration #include <activeds.h> //ADSIs #include <stdio.h> void wmain() HRESULT hr, hre = NULL; //put in scontainerdn the DN of the container to be enumerated 43

44 WCHAR *scontainerdn = L"DC=isqre,DC=net"; WCHAR* sadspath; IADsContainer *pcont; IADs *pad; IEnumVARIANT* penum; VARIANT var; ULONG elts; BSTR bstr; '\0' //initialize COM library hr = CoInitialize(NULL); if (FAILED(hr)) wprintf(l"coinitialize() error: %x\n", hr); return; int size = wcslen(scontainerdn) + 8; // 8 equals "LDAP://" + sadspath = (WCHAR*)malloc(size*sizeof(WCHAR)); //build binding string to the container swprintf(sadspath,l"ldap://%s",scontainerdn); //bind to the container, using an IADsContainer interface hr = ADsGetObject(sADsPath,IID_IADsContainer,(void**)&pCont); if( FAILED(hr)) wprintf(l"error: %x\n",hr); CoUninitialize(); return; //Get an enumerator on the container hr = ADsBuildEnumerator(pCont,&pEnum); if( FAILED(hr)) wprintf(l"error: %x\n",hr); CoUninitialize(); return; VariantInit(&var); //begin enumeration hr = penum->next(1, &var, &elts); while(succeeded(hr)) //getting next contained object if(!elts) break; hre = V_DISPATCH(&var)->QueryInterface(IID_IADs, (void **) &pad); if (SUCCEEDED(hre)) //for each object, print RDN and ADsPath hre = pad->get_name(&bstr); wprintf(l"obj Name: %s\n",bstr); SysFreeString(bstr); hre = pad->get_adspath(&bstr); wprintf(l"\tads Path: %s\n",bstr); SysFreeString(bstr); pad->release(); 44

45 VariantClear(&var); elts = 0L; //get next element in the container hr = penum->next(1, &var, &elts); hr = ADsFreeEnumerator(pEnum); //free COM library CoUninitialize(); END CODE02.CPP In C#, for listing a container, the foreach statement can be used with the objects classes that implement the IEnumerable interface; the whole code becomes more concise. CODE02.CS using System; using System.DirectoryServices; //.NET classes for ADSI class EnumerateContainer static void Main(string[] args) //put in containerdn the DN of the container to be enumerated string containerdn = "DC=isqre,DC=net"; //bind to the container DirectoryEntry cont = new DirectoryEntry("LDAP://" + containerdn); END CODE02.CS //enumerate the containment foreach (DirectoryEntry direntry in cont.children) //for each object, print RDN and ADsPath Console.WriteLine("Obj Name: 0",dirEntry.Name); Console.WriteLine("\tADsPath: 0",dirEntry.Path); cont.dispose(); Searching for Objects in Active Directory As was already mentioned, a key feature for directory services is an effective support to search for the information they contain. In the following examples we will show how LDAP queries can be used in programming to search for objects in AD (see Section ). In this instance as well, the C# code will be more concise than the C++ one. In the ANR (Ambiguous Name Resolution) section following the examples, we will briefly explain the characteristics of the ANR attribute specified in the following examples as first parameter of the LDAP filter. CODE03.CPP 45

46 #include <objbase.h> //CoInitialize and CoUninitialize declaration #include <activeds.h> //ADSIs #include <stdio.h> void wmain() HRESULT hr; IADs *pads; IDirectorySearch *pdsearch; WCHAR *sadspath; VARIANT var; //LDAP filter WCHAR sfilter[] = L"(&(ANR=a)(objectCategory=user))"; //attribute description list WCHAR* arattributes[] = L"distinguishedName", L"sAMAccountName", L"memberOf" ; ADS_SEARCH_HANDLE hsearch; ADS_SEARCH_COLUMN hsclmn; int len; //initialize COM library hr = CoInitialize(NULL); if (FAILED(hr)) wprintf(l"coinitialize() error: %x\n", hr); return; //bind to rootdse and build ADsPath to local Domain NC hr = ADsGetObject(L"LDAP://rootDSE",IID_IADs,(void**)&pADs); if (FAILED(hr)) wprintf(l"adsgetobject() error: %x\n", hr); CoUninitialize(); return; VariantInit(&var); hr = pads->get(l"defaultnamingcontext",&var); pads->release(); if (FAILED(hr)) wprintf(l"iads::get() error: %x\n", hr); CoUninitialize(); return; len = (int) wcslen(var.bstrval) + 8; sadspath = (WCHAR*)malloc(len * sizeof(wchar)); swprintf(sadspath,l"ldap://%s",var.bstrval); VariantClear(&var); /* bind to the local Domain NC, the search base, using an IDirectorySearch interface */ hr = ADsGetObject(sADsPath,IID_IDirectorySearch,(void**)&pDSearch); if (FAILED(hr)) 46

47 wprintf(l"adsgetobject() error: %x\n", hr); CoUninitialize(); return; //search preference values are defined in ADS_SEARCHPREF_ENUM ADS_SEARCHPREF_INFO arsearchpref[2]; //set search scope arsearchpref[0].dwsearchpref = ADS_SEARCHPREF_SEARCH_SCOPE; arsearchpref[0].vvalue.dwtype = ADSTYPE_INTEGER; arsearchpref[0].vvalue.integer = ADS_SCOPE_SUBTREE; //set referral chasing option arsearchpref[0].dwsearchpref = ADS_SEARCHPREF_CHASE_REFERRALS; arsearchpref[0].vvalue.dwtype = ADSTYPE_INTEGER; arsearchpref[0].vvalue.integer = ADS_CHASE_REFERRALS_ALWAYS; //commit search preferences hr = pdsearch->setsearchpreference(arsearchpref, sizeof(arsearchpref)/sizeof(ads_searchpref_info)); //start search hr = pdsearch->executesearch(sfilter,arattributes, sizeof(arattributes)/sizeof(wchar*),&hsearch); if (SUCCEEDED(hr)) //begin processing the result hr = pdsearch->getfirstrow(hsearch); while(hr!= S_ADS_NOMORE_ROWS) //choose columns and print values hr = pdsearch- >GetColumn(hSearch,arAttributes[0],&hSClmn); if (SUCCEEDED(hr)) //print distinguishedname wprintf(l"--> %s\n",hsclmn.padsvalues- >CaseIgnoreString); pdsearch->freecolumn(&hsclmn); hr = pdsearch- >GetColumn(hSearch,arAttributes[1],&hSClmn); if (SUCCEEDED(hr)) //print samaccountname wprintf(l"\tlogon name: %s\n",hsclmn.padsvalues- >CaseIgnoreString); pdsearch->freecolumn(&hsclmn); hr = pdsearch- >GetColumn(hSearch,arAttributes[2],&hSClmn); if (SUCCEEDED(hr)) //print user memberships wprintf(l"\tmember of:\n"); //"memberof" attribute is defined as multivalued for (DWORD i = 0; i < hsclmn.dwnumvalues; i++) wprintf(l"\t %s\n", (hsclmn.padsvalues+i)->caseignorestring); pdsearch->freecolumn(&hsclmn); 47

48 hr = pdsearch->getnextrow(hsearch); pdsearch->closesearchhandle(hsearch); pdsearch->release(); //free COM library CoUninitialize(); END CODE03.CPP CODE03.CS using System; using System.DirectoryServices; //.NET classes for ADSI class LDAPSearch static void Main(string[] args) //bind to rootdse to build local Domain NC ADsPath string sdomainpath = "LDAP://" + (string)(new DirectoryEntry("LDAP://rootdse").Properties["defaultNamingContext"][0 ]); //bind to local Domain partition DirectoryEntry direntry = new DirectoryEntry(sDomainPath); //create a DirectorySearcher that has Domain NC as search base DirectorySearcher dirsearch = new DirectorySearcher(dirEntry); direntry.dispose(); //set LDAP filter dirsearch.filter = "(&(ANR=a)((objectCategory=user)))"; //set search scope dirsearch.searchscope = SearchScope.Subtree; //set referral chasing option dirsearch.referralchasing = ReferralChasingOption.All; //set attribute description list string[] attrstoload = "distinguishedname","samaccountname","memberof"; dirsearch.propertiestoload.addrange(attrstoload); //execute search SearchResultCollection srcoll = dirsearch.findall(); dirsearch.dispose(); //process the result foreach(searchresult sres in srcoll) //print distinguishedname Console.WriteLine("--> 0", sres.properties[attrstoload[0]][0]); //print samaccountname 48

49 Console.WriteLine("\tLogon name: 0", sres.properties[attrstoload[1]][0]); //"memberof" isn't mandatory, we have to check it if (sres.properties[attrstoload[2]]!= null) Console.WriteLine("\tMember of:"); //"memberof" attribute is defined as multivalued foreach (string s in sres.properties[attrstoload[2]]) //print group name Console.WriteLine("\t 0",s); srcoll.dispose(); END CODE03.CS ANR (Ambiguous Name Resolution) ANR is a search mechanism that is related with the LDAP protocol and that is used to simplify the syntax of searches that would need a complex filter. ANR is a logical set located in Active Directory that identifies a collection of attributes. Every time a search filter is specified on the ANR attribute, the filter is expanded and all attributes that make up the ANR set are automatically checked in search for the given value. Here is an example of how the comparison (anr=a) is expanded: ( (displayname=a*)(givenname=a*)(legacyexchangedn=a*) (name=a*)(physicaldeliveryofficename=a*) (proxyaddresses=a*)(samaccountname=a*)(sn=a*)(uid=a*)) Attributes can be added or removed from the ANR set. This kind of inclusion (or exclusion) may be performed by modifying the Schema, by setting to 1 (or 0) the third bit of the searchflags meta-attribute (a bitmask) for each object belonging to the attributeschema class that needs to be added (or removed) to the ANR set. Note: In order to verify which attributes are included in the ANR set, a search can be carried out in the Schema by specifying the following filter: (searchflags: :=4) The OID refers to an LDAP control that is used to execute bit-wise comparisons. In this specific example, a search was carried out for attributeschema objects whose searchflags attribute had set the third bit to 1 (4 in decimal) Object Creation in Active Directory Object creation in AD is limited to a few groups of users. Finding out if one has the necessary rights, at least on the container (or on the OU) that is chosen as the new 49

50 object s parent, is therefore very important. The following examples (C++ and C#) will show how a group can be created. Caution: Carrying out modification tests in domains that are in use is not advisable; they should be executed in appropriate test domains. CODE04.CPP #include <objbase.h> //CoInitialize and CoUninitialize declaration #include <activeds.h> //ADSIs #include <stdio.h> void wmain () HRESULT hr; IADs *pads; IDirectoryObject *pdirobj; IDispatch *pdisp; //new group's Relative Distinguished Name WCHAR snewgroup[] = L"CN=myCppGroup"; ADSVALUE adsclass, adssamname; VARIANT var; WCHAR *sadspath; //initialize COM library hr = CoInitialize(NULL); if (FAILED(hr)) wprintf(l"coinitialize() error: %x\n",hr); return; /* bind to rootdse and build ADsPath to the "Users" container in the local Domain NC */ hr = ADsGetObject(L"LDAP://rootDSE",IID_IADs,(void**)&pADs); if (FAILED(hr)) wprintf(l"adsgetobject() error: %x\n", hr); CoUninitialize(); return; VariantInit(&var); hr = pads->get(l"defaultnamingcontext",&var); pads->release(); if (FAILED(hr)) wprintf(l"iads::get() error: %x\n", hr); CoUninitialize(); return; int len = wcslen(var.bstrval) + wcslen(l"ldap://cn=users,"); sadspath = (WCHAR*)malloc(len * sizeof(wchar)); swprintf(sadspath,l"ldap://cn=users,%s",var.bstrval); VariantClear(&var); /* bind to the "Users" container using an IDirectorySearch interface*/ 50

51 hr = ADsGetObject(sADsPath,IID_IDirectoryObject,(void**)&pDirObj); if (FAILED(hr)) wprintf(l"adsgetobject() error: %x\n", hr); CoUninitialize(); return; //set attribute definitions for the new object ADS_ATTR_INFO arattribs[] = L"objectClass", ADS_ATTR_UPDATE, ADSTYPE_CASE_IGNORE_STRING, &adsclass, 1, L"sAMAccountName", ADS_ATTR_UPDATE, ADSTYPE_CASE_IGNORE_STRING, &adssamname, 1 ; //set new object classschema type adsclass.dwtype = ADSTYPE_CASE_IGNORE_STRING; adsclass.caseignorestring = L"group"; /* set new object "samaccountname" value the same of snewgroup, leaving off the "CN=" naming attribute */ adssamname.dwtype = ADSTYPE_CASE_IGNORE_STRING; adssamname.caseignorestring = snewgroup + 3; //create the group in "Users" container hr = pdirobj->createdsobject(snewgroup,arattribs, sizeof(arattribs)/sizeof(ads_attr_info),&pdisp); if (FAILED(hr)) wprintf(l"adsgetobject() error: %x\n", hr); CoUninitialize(); return; pdirobj->release(); pdisp->release(); //free COM library CoUninitialize(); END CODE04.CPP CODE04.CS using System; using System.DirectoryServices; //.NET classes for ADSI class ADCreate static void Main(string[] args) //bind to rootdse to build local Domain NC ADsPath string sdomainpath = (string) new DirectoryEntry("LDAP://rootdse").Properties["defaultNamingContext"][0 ]; /* bind to the "Users" container in the local Domain NC; this will be the parent of the new object */ DirectoryEntry decont = new DirectoryEntry("LDAP://CN=Users," + sdomainpath); 51

52 //set new object name string snew = "mycsgroup"; //create the new group object DirectoryEntry denew = decont.children.add("cn=" + snew,"group"); decont.dispose(); //set "samaccountname" value the same as object name denew.properties["samaccountname"].add(snew); //save object creation and attribute update to the directory denew.commitchanges(); denew.dispose(); END CODE04.CS Note: Object creation takes place only if a value is provided for all its mandatory attributes (see Section Attributes). Some of these values may not be explicitly defined by the programmer: when committing the creation (the transaction is activated by the SetInfo() call in C++ and by the CommitChanges() in C#), these values are set automatically by deriving them from other parameters or by using default values. For instance, creating a group in a.net environment we need only the Relative Distinguished Name and the class name to successfully carry out the operation. If one does not want to use default values or in order to avoid potentially difficult situations, other parameters should be included. For instance, if a value for grouptype is not specified, the group will be created with global visibility and security type; if a different visibility or type are required, the right flag combinations (as defined in the iads.h header) should be provided, as shown in Table 7. Group Domain Local Distribution Domain Local Security Global Distribution Flag ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP ADS_GROUP_TYPE_SECURITY_ENABLED ADS_GROUP_TYPE_GLOBAL_GROUP Global Security ADS_GROUP_TYPE_GLOBAL_GROUP ADS_GROUP_TYPE_SECURITY_ENABLED Universal ADS_GROUP_TYPE_UNIVERSAL_GROUP Distribution Universal Security ADS_GROUP_TYPE_UNIVERSAL_GROUP ADS_GROUP_TYPE_SECURITY_ENABLED Table 7 As far as uninitialized attributes that generate uncomfortable values are concerned, if the samaccoutname value (i.e. the string used as a logon name during 52

53 the authentication process) is not specified a unique value is automatically generated, e.g. $h31000-ph4d3adpule8 ;this is a valid logon name but, obviously, is not user-friendly Creation of Application Directory Partitions At the beginning of this paper, we referred to Application Directory Partitions (ADP). These partitions were created to cover the need for dynamic data publication in a repository with the distribution, replication and security characteristics of Active Directory. Note: In Windows.NET, a new auxiliary class, called dynamicobject, has been defined. It allows the association of a predefined lifetime to a directory element (in the entryttl attribute). In order to make an object dynamic, a reference to the dynamicobject class in the objectclass attribute of the object itself must be added (dynamic linking). In order to make a whole class of objects dynamic, their definition in the Schema must be changed by adding the dynamicobject class reference to the auxiliaryclass attribute (static linking). ADPs are domaindns class objects and can contain any object that is already defined in the Schema, except for objects identified as security principals, i.e. users, groups and computers. A domaindns class instance can be created as a child of another domaindns object, which means that an Application Partition can be logically nested in another one. The following code section will show how to create an ADP. Apart from the RDN and the class (domaindns), the only other information that is needed to create an Application Partition is the value for the instancetype attribute. This attribute must be set to 5, which corresponds to the logical OR of the DS_INSTANCETYPE_IS_NC_HEAD and DS_INSTANCETYPE_NC_IS_WRITEABLE flags, that are defined in the ntdsapi.h file and that respectively indicate that the object being created is the root (head) of a Naming Context and that objects may be written, i.e. instantiated inside it. CODE05.CS using System; using System.DirectoryServices; //.NET classes for ADSI class ADCreateADP static void Main(string[] args) //bind to rootdse to build local Domain NC ADsPath string sdomainpath = (string) new DirectoryEntry("LDAP://rootdse").Properties["defaultNamingContext"][0 ]; //bind to local Domain NC, as the parent of the new object DirectoryEntry decont = new DirectoryEntry("LDAP://" + sdomainpath); //set new ADP's Relative Dinstinguished Name 53

54 string snewadp = "DC=myCsADP"; //create a new ADP as a new domaindns object DirectoryEntry denewadp = decont.children.add(snewadp,"domaindns"); //set "instancetype" as (DS_INSTANCETYPE_IS_NC_HEAD DS_INSTANCETYPE_NC_IS_WRITEABLE) denewadp.properties["instancetype"].add(5); denewadp.commitchanges(); END CODE05.CS denewadp.dispose(); This operation automatically triggers a series of procedures that lead to the creation of the crossref object in the Partitions container inside the Configuration Naming Context, to the addition of the new partition s Distinguished Name in the ntdsdsa object s hasmasterncs attribute (the ntdsdsa object identifies the Directory Service Agent of the DC where the partition is being created), and to the addition of a new zone and of the necessary SRV records in the DNS. Note: The DNS is updated every time an ADP partition replica is added or removed. As previously mentioned, ADPs may contain dynamic data that could be frequently modified, which could generate an undesirable amount of network traffic during replication. For this reason, these special Naming Contexts are replicated on other Domain controllers only following a specific request of the administrator. This operation is carried out by modifying the crossref object connected with the Application Partition and by adding the Distinguished Name, that identifies the replication DC s Directory Service Agent, to the msds-nc-replica-locations attribute. Once the replication partners are defined, intra-site replication intervals can be specified by setting the following two attributes of the same cross reference: msds-replication-notify-start-delay: It allows setting of the time (in seconds) after which the first replication partner must be informed of a modification. If not set, a default value of 5 minutes will be applied. msds-replication-notify-subsequent-dsa-delay: It allows setting of the time after which the successive replication partners must be notified. If not set, a default value of 30 seconds will be applied. Note: Intra-site replication intervals can be personalized by modifying the DC register; this setting has priority over the values defined by the cross reference attributes. On the other hand, ADP inter-site replication follows the same replication schedule that is applicable to Domain partitions. 54

55 Every Application Directory Partition may have any forest Domain Controller as a replication partner, but it is not replicated in the Global Catalog. Note: ADP can be removed by connecting to one of the.net Server family DCs and by deleting the crossref, whose value of the ncname attribute corresponds to the Distinguished Name of the domaindns connected with the partition to be removed. Upon completion of this operation, the KCC (Knowledge Consistency Checker) triggers a series of procedures that lead to the deletion of the partition replications, of instances of the domaindns object that was created with the partition, and of all the other objects within. The partition s DNS zone and its content are also removed. Deleting an ADP does not generate tombstones. Appendix Additional Programming Examples ADSQL.CS: Example of a search carried out in Active Directory by using an OleDB provider and SQL-like syntax for the query. WinNT_1.CS: It shows how an Active Directory account can be inserted into one of a machine s local groups. WinNT_2.CS: It lists the services that are being executed on a machine; if a service name is specified, its status is inverted. ADSQL.CS using System; using System.Collections; using System.Data; using System.Data.OleDb; class ADSql static void Main(string[] args) //set the OLEDB provider for Active Directory OleDbConnection oledb = new OleDbConnection("Provider=ADsDSOObject;"); oledb.open(); //set attribute description list string searchattrs = "distinguishedname, objectcategory"; //set an ADsPath for the search base string searchbase = "'LDAP://DC=isqre,DC=net'"; //set filter string searchfilter = "objectclass='user'"; //build SQL query string string searchquery = "SELECT " + searchattrs + " FROM " + searchbase + " WHERE " + searchfilter; 55

56 oledb); OleDbDataAdapter oleda = new OleDbDataAdapter(searchQuery, //object that will cache the data retrieved from AD DataSet oleds = new DataSet(); //retrieve data from AD oleda.fill(oleds,"obj"); oledb.dispose(); oleda.dispose(); foreach (DataRow r in oleds.tables["obj"].rows) //process the result Console.WriteLine("-->"); for (int i = 0; i < r.itemarray.length; i++) Console.WriteLine(" 0",r.ItemArray[i].ToString()); oleds.dispose(); END ADSQL.CS WinNT_1.CS using System; using System.DirectoryServices; //.NET classes for ADSI using ActiveDs; // native ADSI class Account2lg static void Main(string[] args) // modify writing in your own valid values string host = " "; // IP address or netbios name string localgroup = "power users"; string domain = "ISQRE"; //domain netbios name, or a DC's IP address or netbios name string domainaccount = "colomboem"; // an existent account //bind to the specified local group object DirectoryEntry de = new DirectoryEntry("WinNT://" + host + "/" + localgroup); //get a native IADsGroup interface on the local group object IADsGroup group = (IADsGroup) de.nativeobject; //add the specified domain account to the local group group.add("winnt://" + domain + "/" + domainaccount); de.dispose(); END WinNT_1.CS WinNT_2.CS /* * In order to use ADSI native interfaces, you need to build * the code linking the activeds.tlb template library */ using System; using System.DirectoryServices; //.NET classes for ADSI 56

57 using ActiveDs; // native ADSI class StopService static void Main(string[] args) // modify writing in your own valid values string hostname = "Host1"; //host's IP address or netbios name string servicename = "alerter"; string newstatus = "0"; // bind to the chosen computer DirectoryEntry de = new DirectoryEntry("WinNT://" + hostname); //set a filter to enumerate only "service" objects de.children.schemafilter.add("service"); Console.WriteLine("Services running on host 0:",hostName); foreach (DirectoryEntry svc in de.children) /* get a native IADsServiceOperation interface on the current service object */ IADsServiceOperations serv = (IADsServiceOperations) svc.nativeobject; if (String.Compare(svc.Name,serviceName,true) == 0) //the current service is the one indicated above if (serv.status == 1) //requested service is stopped serv.start(); newstatus = "started"; Console.WriteLine(" " + svc.name); else if (serv.status == 4) //requested service is running serv.stop(); newstatus = "stopped"; else if (serv.status == 4) //service is running Console.WriteLine(" " + svc.name); svc.dispose(); de.dispose(); if (newstatus.length == 1) Console.WriteLine("\nNone operation has been performed on service 0",serviceName); else Console.WriteLine("\nService 0 has been 1.", servicename,newstatus); END WinNT_2.CS 57

58 Tools for AD Management and Analysis ADSIEDIT (Support Tools) A graphic tool that allows interaction with AD via LDAP: provider. Support Tools are included in the installation CD of the Windows.NET e 2000 operating systems and must be explicitly installed. Once Support Tools are installed, ADSIEDIT is a component of the MMC (Microsoft Management Console). After opening the MMC, choose File \ Add- Remove Snap-in. For further information, please refer to the online help. ADSVW.exe (ADSI SDK) An ADSI application that belongs to the SDK Platform tools, it is one of the most versatile. The SDK Platform may be found at the Microsoft site. Csvde.exe It is a command line tool used to retrieve/insert data in AD in CSV (Comma Separated Value) format; if executed with no parameters, a help menu is displayed. LDIFDE.exe (LDAP Data Interchange Format Directory Exchange) It is a command line tool used to insert and modify objects in LDAP servers. LDIF is a draft Internet standard defined in RFC For further information, see: US;Q237677& LDP.exe (Support Tools) It is a graphic tool that is part of the Support Tools. It is used to query an LDAP directory service. For further information, please refer to the online help. Ntdsutil.exe It is a powerful and articulated command line tool that is used to interact with the AD database (ntds.dit) directly; it is particularly useful for DSA troubleshooting when the directory service is inactive. Do not use this tool without carefully reading its documentation (see and without thoroughly understanding AD and its domain functions. Repadmin.exe (Support Tools) It is used to analyze and troubleshoot replication. For further information, see the Support Tools help. Schema Manager This component, called Active Directory Schema, is one of the MMC (Microsoft Management Console) snap-ins. Before using it, it must be registered with the Regsvr32 command line tool as follows: 58

59 C:\>Regsvr32 schmmgmt.dll In Windows.NET AD version some of the listed tools have been updated to the new features. In particular, ntdsutil.exe and ADSIEDIT allow to add and remove ADP partitions. Furthermore a few new command line tools have been introduced in Windows.NET: dsadd (to add objects to AD) dsget (to visualize AD objects) dsmod (to modify them) dsmove (to move them) dsquery (to retrieve objects according to specific search criteria) dsrm (to remove objects) These tools are useful for non-programming interaction with AD, since they work via shell or via shell scripts. For each one of these tools, the /? switch displays a concise help menu. Caution: Most of the tools mentioned above are used not only for reading but also for modifying AD values and must therefore be used with caution. The authors suggest use in test environments only and do not accept responsibility for malfunctioning due to their application. 59

60 Bibliography Active Directory [1] A.A. V.V. Microsoft Windows 2000 Security Technical Reference, Redmond, Washington, Microsoft Press, [2] A.A. V.V., Windows 2000 Server Distributed System Guide, in Windows 2000 Server Resource Kit, Microsoft Press, Redmond, Washington, [3] A.A. V.V., Building Enterprise Active Directory Services: Notes from the Field, Microsoft Press, Redmond, Washington, [4] COULOURIS G., DOLLIMORE J., KINDBERG T., Distributed Systems Concept and Design, Addison-Wesley Publishers, Wokingham, [5] ISEMINGER D., Active Directory Service for Microsoft Windows 2000 Technical Reference, Microsoft Press, Redmond, COM [6] EDDON G., EDDON H., Inside COM+ Base Services, Microsoft Press, Redmond, Washington, C# [7] ARCHER T., Inside C#, Microsoft Press, Redmond, Washington [8] WILLIAMS M., Microsoft Visual C#.NET, Redmond, Washington, System Architecture [9] SILBERSCHATZ A., GALVIN P.B., Sistemi Operativi, Addison Wesley Longman Italia, Milano, [10] SOLOMON D.A., RUSSINOVICH M.E., Inside Windows 2000, Microsoft Press, Redmond, [11] TANENBAUM A.S., Architettura dei computer un approccio strutturato, UTET Libreria, Torino, [12] TANENBAUM A.S., Modern Operating Systems, Prentice Hall International Editions, Upper Saddle River, TCP/IP [13] A.A. V.V., Windows 2000 Server - TCP/IP Core Networking Guide, in Windows 2000 Server Resource Kit, Microsoft Press, Redmond, [14] COMER D., Internetworking With TCP/IP, Volume 1, Principles Protocols, and Architecture, Prentice Hall, Upper Saddle River,

61 By the Same Authors and Related to this Topic: Books [15] PINARDI S., ARUANNO T.A., BISIANI R., Windows 2000 &.NET in Action, UTET Libreria, Torino, (in Italian). White Papers [16] PINARDI S., FEDRICI A., BISIANI R., Distributed Programming Using C#: a Case Study, Microsoft, [17] ARUANNO A., PINARDI S., FEDRICI A., BISIANI R., Processes, Threads and Synchronization Matters in Windows.NET and others NT Based Operating Systems, Microsoft, For further information about the authors and other related material, see Web References System Engineering Microsoft s basic knowledge. An operating approach to system engineering themes in a Microsoft environment. Programming A programming guide for Microsoft environments. A.NET programmer s guide with many examples. Examples and programs on ADSI. 61

62 RFC X