What is Talloc DLL missing

Institute for Telecommunications Laboratory for Computer Science. Bachelor thesis. Stefan Metzmacher


1 University of Applied Sciences Cologne University of Applied Sciences Cologne 07 Faculty of Information, Media and Electrical Engineering, course: Information Engineering Institute for Telecommunications Laboratory for Computer Science Bachelor thesis Topic: Subtitle: Active Directory Replication Documentation and analysis of the DRSUAPI replication protocol, as well as a partial implementation of the replication of Windows to Samba 4.0. Student: Matriculation number: Stefan Metzmacher Speaker: Co-supervisor: Prof. Dr. phil. Gregor Büchel Prof. Dr.-Ing. Andreas Grebe submission date:

2 Active Directory Replication ii I hereby confirm that I wrote the bachelor thesis myself and that I have not used any sources or aids other than those indicated and indicated in quotations. Stefan Metzmacher

3 Active Directory Replication iii Table of Contents 1 Introduction Problem What is Active Directory? What is samba Why is the topic important? Samba should be a domain controller for Active Directory What are the difficulties Why partial implementation Preliminary work Student work Active Directory replication Development within the Samba project Objective Implementation of the function libnet_becomedc () Implementation of a schema API Implementation of an LDB module for storing the replication - Metadata requirements and delimitations Description of the replication system What is a directory service Overview RootDSE directory objects The partitions Basic protocols Authentication protocols LDAP CLDAP SMB DCERPC DCERPC based interfaces / protocols SAMR NETLOGON DRSUAPI Basic concepts of the replication system Source-DSA vs. Destination-DSA Singlemaster replication vs. Multimaster replication Push replication vs. pull replication Log-based vs. status-based replication Store-and-forward replication Basic attributes and structures The objectguid attribute The objectsid attribute The structure DsReplicaObjectIdentifier The object NTDS Settings The attribute highestcommitedusn The structures DsReplicaCursor and DsReplicaCursorCtr The structure DsReplicaHighWaterMark The attributes repsfrom and repsto ... 22

4 Active Directory Replication iv ASN.1 Object Identifier The Prefix Mapping The structures DsReplicaOIDMapping and DsReplicaOIDMapping_Ctr Originating-Updates vs. 58

5 Active Directory replication v Creating a test computer account Promoting to domain controller Downgrading and deleting the computer account Executing NET-API-BECOME-DC via smbtorture Conclusion What has been achieved What else has to be done Bibliography Abbreviations Index Appendix A1 drsblobs .idl A2 drsuapi.idl A3 samdb.h A4 schema.h A5 libnet_become_dc.h A6 libnet_unbecome_dc.h A7 torture_libnet_becomedc.c A8 libnet_become_dc.c A9 libnet A14 schema_fsmo.c A15 show_deleted.c A16 Contents of the enclosed CD A17 Instructions for Samba

6 Active Directory Replication vi List of Figures 3.1 A typical directory tree with directory objects A typical RootDSE object (a few attribute values ​​were removed to improve the overview) A typical domain forest under Windows A typical directory object with an overview of the attributes Network protocols (cf. 0 (cf. Replication Subsystem Components in [MSTN01]) Overview of the LDB modules that are used in the DSDB subsystem

7 Introduction 1 1 Introduction In today's IT world, directory services play a central role. They offer a central storage space for user accounts 1 including group memberships and software configurations of all kinds. Directory services also offer user authentication and controlled, configurable policies for accessing the objects and their attributes stored in the directory. From the point of view of IT managers in companies, it is desirable to be able to choose freely between alternative products on the directory services market. The most important aspect here is that all information stored in the directory can also be exported again in order to switch to another product. According to the motto: My data belongs to me and not to the software that manages it !. From the point of view of the product manufacturer, it is desirable to bind the customer to their own product. With all products, almost all data is accessible via the Lightweight Directory Access Protocol (LDAP) [RFC4510], a standardized network protocol for accessing directory services. However, access to user passwords is not possible with most proprietary products, even via encrypted data connections with administrator privileges. However, since in most environments several servers keep copies of the directory data for reasons of redundancy, non-standardized network protocols are usually used to compare the data, including the user passwords. This fact ensures that a customer is bound to a certain product, since in most cases it is practically impossible to assign a new password to every user. The market leader Microsoft also uses a proprietary replication protocol called Directory Replication Service Update API (DRSUAPI) in its directory service Active Directory, which was analyzed in this bachelor thesis. 1.1 Problem What is Active Directory? Microsoft's directory service is called Active Directory and is part of the Windows 2000 Server and Windows 2003 Server products. Active Directory assumes the role of the so-called domain controller (DC) in Windows domains, which is responsible for user administration and user authentication. Windows 2000 is sometimes abbreviated as W2K and Windows 2003 as W2K3. In the case of Windows NT4 domains, only proprietary network protocols such as B. SAMR and LSA used for user administration. NTLMSSP and NETLOGON / SCHANNEL were used as authentication protocols. In addition, there was no directory service, but a Security Account Manager (SAM), which saved the users and groups in the Windows registry. Under Windows-NT4, a distinction was made between primary domain controller (PDC) and backup domain controller (BDC), whereby write access could only take place on the PDC. Active Directory integrates a number of modern network and authentication protocols, such as B. LDAP, DNS, Kerberos 5 2 and DIGEST-MD5. In addition, however, 1 is always used. User accounts refer to user accounts. 2 Also known as Kerberos-V or Krb5

8 Problem 2 still supports the old NT4 protocols. The NT Directory Service (NTDS) now forms the data basis for all supported protocols and forms the main component of the Active Directory. The Active Directory authentication protocols are typically used to authenticate file and printer access using the SMB protocol 3, but also for e-mail or web services. What is Samba? Samba is a software package that provides file and printer services compatible with Microsoft products under Unix / Linux operating systems. Samba is free software and available under the GNU General Public License (see [SaTe04], [FSF01], [FSF02] and [WikiPe02]). Samba has been developed by Andrew Tridgell since 1992 and by the Samba team since 1996. Tridgell wanted to access the hard drive of his Sun Sparcstation from his PC with Pathworks for DOS and wrote a server program for it without knowing that the protocol used was Server Message Block (SMB). At that time Microsoft was still very small on the market, but this changed with the introduction of Windows NT3.5 and later Windows NT4. Microsoft built its proprietary authentication and user management protocols on top of the SMB and DCERPC protocols. Among other things, SMB and DCERPC were provided with undocumented extensions. The aim of the Samba team is to be as compatible as possible with Microsoft products. For this purpose, some methods for network analysis have been developed (see [Tridge01] and [Tridge02]). Today version 3.0 of Samba is for the most part compatible with Microsoft products as a file, print and logon server. Since 2004 some members of the samba team, including Andrew Tridgell, Andrew Bartlett, Simo Sorce, Jelmer Vernooij and the author of this bachelor thesis, have been working on a major overhaul of the aging Samba source code. One goal of this restructuring is an Active Directory-compatible implementation of a domain controller with support for all relevant protocols. The new version is called Samba 4.0, although currently only Technology Previews, which are purely developer versions, are published. Alpha status has not yet been achieved. Why is the topic important? Samba is most often used in combination with the free operating system Linux (see [FSF01], [FSF02] and [WikiPe02]). More and more IT managers appreciate the fact that everyone can view and expand the source code of Linux and Samba. Backdoors and espionage programs are often suspected in proprietary software, which makes free software such as Linux and Samba particularly interesting for governments. Among other things, the German Bundestag also uses Samba in combination with Linux. In many cases, license costs that are not incurred also play a major role in the decision for Samba. In addition, Linux and Samba can keep up very well with Windows servers in terms of stability, performance and security. The Samba team repeatedly receives inquiries from users as to whether or when Samba can replace a domain controller for Active Directory. Many would like to switch from Windows servers to Samba servers, but they need some special properties from Active Directory. 3 Also known as the CIFS protocol.

9 Problem Samba should be a domain controller for Active Directory In order to turn Samba 4.0 into an Active Directory compatible domain controller, an LDAP server and a Kerberos server 4 were built into the server program smbd. As of today, Samba 4.0 can already act as an Active Directory domain controller for Windows domain members 5. In detail, this means that a Windows member computer willingly joins a domain controlled by Samba 4.0, believing it is a domain controlled by Windows 2003 servers. You can then log in to the member computer with Kerberos authentication using a domain user account. In order to manage a domain as an equivalent domain controller alongside Windows servers, Samba 4.0 still lacks some capabilities. At the moment, access protection for directory objects is only regulated in a very trivial way, i. H. an administrator can read and write all data, and everyone else can read anything but passwords. In addition, written data is not checked for syntactic correctness, i. H. there is no so-called directory scheme which defines the structure of the objects and their hierarchy as well as the syntax of the object attributes. The most important missing function, however, is the synchronization of the directory data with the Windows colleagues in order to always have an up-to-date replica of the directory. The process of matching is generally called replication and is the main topic of this bachelor thesis. What are the difficulties? There is now good documentation about the technologies and concepts used in Active Directory. These are offered by Microsoft itself on the Microsoft TechNet and Microsoft MSDN Internet portals (see [MSTN01], [MSTN02], [MSTN03], [MSTN04], [MSTN05], [MSTN06] and [MSDN01]). However, these are aimed exclusively at administrators and therefore do not contain any documentation of the network protocols used. Accordingly, the main difficulty in implementing the DRSUAPI replication protocol lies in the fact that it is not, like e.g. For example, there is a published specification for LDAP or Kerberos 5. Due to the lack of specification, the use of the methods described by Tridgell is required to develop a network protocol specification (see [Tridge01] and [Tridge02]). Why partial implementation A complete implementation of DRSUAPI server and DRSUAPI client as well as all administration tools would be beyond the scope of this By far exceed the bachelor thesis. Therefore, only the points described in the chapter on objectives are dealt with in this bachelor thesis. 4 A Kerberos Key Distribution Center (KDC) 5 This is the name given to workstations and servers that usually do not have any local user accounts and use the authentication services of the domain controller.

10 Preparatory work Preparatory work Student thesis Active Directory Replication This bachelor thesis builds on the student thesis Active Directory Replication in the subject of data networks, by Michael Kohlgraf and the author of this bachelor thesis (see [KoMe2005]). In the thesis, layers 5 (session layer) and 6 (presentation layer) of OSI model 6 of the DRSUAPI protocol were analyzed. The NDR coding 7 and the interface definition with the help of IDL 8 were discussed in particular. However, the DsGetNCChanges () function used for replication has not yet been explored. Development as part of the Samba project As part of the development of Samba 4.0, I continued to research the DRSUAPI protocol. The IDL descriptions for the functions DsGetNCChanges (), DsAddEntry () and DsReplicaUpdateRefs () required for replication were also developed. Samba 4.0 has a test program smbtorture, with which network protocols and internal interfaces can be tested. A new test called RPC-DSSYNC has been added here, which demonstrates the functionality of DsGetNCChanges (). This made it possible to understand how directory objects and their attributes are transferred. However, some details were still unclear, such as B. the connection-specific encryption of various password attributes. Samba 4.0 provides all the technologies required for replication, such as Kerberos-5, LDAP and DCERPC are available. This bachelor thesis is therefore based on Samba 4.0, whereby the developments flow back into the Samba source code. Within this bachelor thesis reference is only made to the developer version Samba 4.0. Therefore, in the following chapters, the explicit version 4.0 is omitted and Samba implicitly means Samba 4.0. 6 Also called the 7-layer model (see [WikiPe01]) 7 Network Data Representation (see [OpGr02]) 8 Interface Definition Language (see [OpGr03])

11 Objectives 5 2 Objectives This chapter defines the objectives of this bachelor thesis. 2.1 Implementation of the function libnet_becomedc () As part of this bachelor thesis, the function libnet_becomedc () is to be implemented, which has the server role 1 of a Samba server in an Active Directory domain controlled by Windows 2003 servers in mixed mode 2 of Domain member changes to domain controller. For this purpose, Samba's management API LIBNET is extended by the function libnet_becomedc (). For completeness, the function libnet_unbecomedc () is also implemented, which changes server role 1 back to a domain member. However, for reasons of size, only the libnet_becomedc () function is explained in detail. 2.2 Implementation of a schema API Within Samba's DSDB component 3, a schema API including a schema cache is to be developed in order to enable access to the directory schema 4. The schema cache is implemented using the C structures struct dsdb_schema, struct dsdb_class and struct dsdb_attribute. Whereby struct dsdb_schema forms a container for struct dsdb_class or struct dsdb_attribute instances. The schema API then offers C functions for accessing the schema cache. A schema cache with a schema API is absolutely necessary for successful replication, since otherwise some parts of the replication messages cannot be interpreted. As part of this bachelor thesis, the schema API is only implemented for this purpose. Use of the schema API to validate write access to directory objects is not taken into account here. In addition, an LDB module 5 with the name schema_fsmo is being developed. Among other things, this module should later validate write access to directory schema 4, since write access under Active Directory is only possible on a selected server, the so-called schema master 6. In the context of this bachelor thesis, however, only the loading of the schema cache for use in the schema API is developed. 1 The following server roles are defined: Standalone, domain member and domain controller 2 Active Directory domains can be operated in two modes. Windows NT4 backup domain controllers are supported in mixed mode, for this reason some functions of Active Directory, such as e.g. nested group memberships, deactivated. Only Active Directory domain controllers are supported in native mode. The mode is specified when installing Active Directory and can only be changed later from mixed mode to native mode, but not vice versa. 3 DSDB stands for Directory Service Database 4 The directory schema contains attribute and class definitions that regulate the structure and hierarchy of the objects stored in the directory. 5 LDB (Lightweight Database) is Samba's LDAP-like interface for storing LDAP-like objects. LDB is very strongly modularized and can be expanded with LDB modules in order to expand the functions with regard to the public LDB API.

12 Prerequisites and Limitations Implementation of an LDB module for storing the replication metadata In order for Samba to save the metadata required for replication, an LDB module 5 with the name repl_meta_data is being developed.In the case of direct write access to directory objects, this module should create the metadata required for replication and save it in the replpropertymetadata attribute of the respective object. This task is only implemented as an example for the ldb_add () function in the context of this bachelor thesis. The dsdb_extended_replicated_objects_commit () function, which applies the changes contained in a replication message to the local directory data, is also implemented within the DSDB component 3. The changes are first prepared using the schema API and then transferred to the LDB layer using a so-called LDB Extended Operation 7 called DSDB_EXTENDED_REPLICATED_OBJECTS_OID via the ldb_extended () function. The LDB module repl_meta_data accepts this request and applies the changes. 2.4 Requirements and delimitations In the course of the processing time, Samba will be further developed on a daily basis and new knowledge will be incorporated every week. Therefore, in this bachelor thesis, some discoveries can only be partially addressed in order not to exceed the time frame. Since the topic of the bachelor thesis is a very special topic, basic knowledge in the fields of computer science, databases, data networks, operating systems, distributed systems as well as knowledge of LDAP and directory services are required. In addition, the existing Samba C functions cannot be explained; the entire Samba 4.0 source code is available under [SaTe01] (see also [SaTe02]). In the context of this bachelor thesis, the treatment of so-called linked attributes 8 for the implementation is completely disregarded. 6 The following 5 Flexible Service Operation Master roles are defined in Active Directory: Schema Master, Domain Naming Master, RID Master, PDC Emulator Master and Infrastructure Master (see also [MSTN03]) 7 With the help of LDB Extended Operations can be used to add new functions to the LDAP protocol or the LDB API. 8 Linked attributes are attributes that store references to other directory objects. These attributes always appear as a pair, whereby there is a forward link and a backward link, which each refer to the other object. Only the forward link can be changed at a time, the backward link is always adapted automatically. In the case of replication, only the forward link is transmitted, and the backward link must be generated automatically. In an Active Directory domain in native mode, linked attributes are replicated separately from the objects.

13 Description of the replication system 7 3 Description of the replication system The following chapter introduces the basic replication model. The technologies used are also briefly explained. The descriptions refer to the Microsoft Technet document How the Active Directory Model Works [MSTN01]. In addition, test programs created by the Samba team provide proven facts, which are also included in the descriptions, as no specifications whatsoever can be found in [MSTN01]. 3.1 What is a directory service Overview A directory service stores directory objects in a tree structure called the Directory Information Tree (DIT). Figure 3.1 shows the view of a DIT in an LDAP client with a graphical user interface. Each object has a Distinguished Name (DN), e.g. B. OU = newtop, DC = sub1, DC = w2k3, DC = vmnet1, DC = vm, DC = base, whereby the individual components of the DN are referred to as Relative Distinguished Name (RDN). In the example, OU = newtop is the RDN of the object and DC = sub1, DC = w2k3, DC = vmnet1, DC = vm, DC = base is the parent object. OU = newtop, DC = sub1, DC = w2k3, DC = vmnet1, DC = vm, DC = base is therefore a child object of DC = sub1, DC = w2k3, DC = vmnet1, DC = vm, DC = base. In general, the namespace of the directory is global in relation to the Internet. However, each Directory Service Agent (DSA) 1 only stores part of the entire namespace. However, every DSA offers the root object, which has an empty DN and is referred to as the Root DSA-specific Entry (RootDSE). 1 The directory service server instance is called the Directory Service Agent in English.

14 What is a directory service 8 Figure 3.1 A typical directory tree with directory objects RootDSE Figure 3.2 shows the RootDSE object of a Windows 2003 server in LDAP Data Interchange Format (LDIF) [RFC2849] 2. With the namingcontexts attribute, the DSA indicates which parts of the global namespace it offers. Windows 2003 servers also offer the attributes defaultnamingcontext, configurationnamingcontext, schemanamingcontext and rootdomainnamingcontext (see Figure 3.2). Each domain controller stores at least three writable directory partitions 3: the domain partition, the configuration partition and the schema partition. Figure 3.3 shows a so-called domain forest, in which several domain trees are logically grouped together. There is only one configuration partition and only one schema partition per forest. The rootdomainnamingcontext attribute always contains the DN of the root domain in the domain forest, while the defaultnamingcontext attribute always contains the DN of the local domain for which the DSA is responsible. I. E. that each DSA can only manage one domain at a time. The DNs of the domains are based on their DNS names. In the example, sub1.w2k3.vmnet1.vm.base is the DNS domain name. There are also application partitions and non-writable partition copies. On these two special 2 The first line always contains the DN of the object preceded by dn :. Objects always consist of their DN and a number of object attributes. All following lines up to the next blank line are pairs of attribute name and attribute value. If a line begins with a space, the following characters still belong to the attribute value of the previous line. In the case of attribute values ​​that can be represented as an ASCII character string, the attribute name and attribute value are separated by:. If this is not possible, the attribute value is encoded using Base64 [RFC4648] and :: is used to separate the attribute name and attribute value. 3 Directory partition is a synonym for naming context (NC). The term directory partition is used in this bachelor thesis.

15 What is a directory service? 9 cases are not dealt with in this bachelor thesis. Figure 3.2 A typical RootDSE object (a few attribute values ​​have been removed to improve the overview).

16 What is a directory service 10 Figure 3.3 A typical domain forest under Windows Directory objects Figure 3.4 shows an example of a directory object. The objectclass attribute has a special role because objects are instantiated object classes. The directory schema contains the definitions of attributes and object classes, which in turn are instances of the object classes attribute schema or classschema. Object classes define which attributes are mandatory or optional for an object. In addition, object classes can inherit properties from other classes, e.g. B. every class is derived from the super class top. For attributes, among other things, it is defined whether several attribute values ​​are permitted for an object or which syntax requirements attribute values ​​must meet. If you want to know more about inheritance and other details of the directory schema used in Active Directory, you will find a good description under [MSTN04] (see also source / setup / schema.ldif under [SaTe01]).

17 What is a directory service 11 Figure 3.4 A typical directory object with attributes The partitions The schema partition All information on the directory schema is stored in the schema partition (see also [MSTN05]). The configuration partition All configuration information relating to the entire domain forest is stored in the configuration partition (see also [MSTN05]). These include e.g. Information on all domain controllers and their locations. In addition, information about all directory partitions in the domain forest is saved here. The domain partition All data relevant to the respective domain are stored in the domain partition (see also [MSTN05]). This includes user and computer accounts as well as user groups. Domain-related configuration data is also stored here.

18 Basic Protocols Basic Protocols A number of basic protocols are used in Active Directory. The basis is formed by the Internet Protocol (IP) [RFC791] and, based on it, the Transmission Control Protocol (TCP) [RFC793] and the User Datagram Protocol (UDP) [RFC768]. The Domain Name Service (DNS) [RFC1034, RFC1035] and Netbios Name Service [RFC1001, RFC1002] protocols are used to resolve names to IP addresses. Authentication protocols The interaction of the network protocols is shown in Figure 3.5. All protocols above TCP use authenticated sessions, with Kerberos 5 (KRB5) [RFC4120] and New Technology Lan Manager Secure Service Provider (NTLMSSP) [Gla2006] being used as authentication protocols. In some cases, additional protocols such as Generic Security Service Application Program Interface (GSSAPI) [RFC2743], Simple and Protected Negotiation (SPNEGO) [RFC4178] and / or Simple Authentication and Security Layer (SASL) [RFC2222] are used to negotiate the respective protocol.

19 Basic protocols 13 Figure 3.5 Overview of the network protocols (cf. Replication and LDAP Client-Server Architecture in [MSTN01]) LDAP The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a protocol that allows access to directory objects and their attributes enables. The protocol is based on TCP and uses the TCP port 389. Typically, a client must authenticate itself with the server using ldap_bind (). Then the functions ldap_add (), ldap_modify (), ldap_modify_rdn () and ldap_delete () are available for editing a specific directory object. The ldap_search () function is also used to list directory objects. The base DN restricts the search to a specific subtree of the directory hierarchy. To further limit the search, a search area is created using LDAP_SCOPE_BASE (only Base-DN), LDAP_SCOPE_ONELEVEL (only direct child objects of Base-DN) or

20 Basic protocols 14 LDAP_SCOPE_SUBTREE (all objects below Base-DN and Base-DN itself) specified. In order to only list objects with certain attribute values, the search filter determines, e. B. (& (objectclass = user) (name = administrator)) which objects the server should send to the client. Finally, an attribute list indicates which attributes of the objects found are to be returned. For the search filter and the attribute list, * may be used as a wildcard. CLDAP The Connectionless Lightweight Directory Access Protocol (CLDAP) [RFC3352] is the connectionless variant of LDAP. It is based on UDP and does not use authentication. As a result, only search queries are supported. SMB The Server Message Block (SMB) 4 [Her2003] protocol is connection-oriented and based on TCP. Both TCP port 139 and TCP port 445 are used. In the case of port 139, the Netbios Session Service [RFC1001, RFC1002] is formally located between SMB and TCP, but this is only noticeable when the connection is established through two additional protocol messages. SMB provides file system and printer sharing. The special IPC $ release also enables communication via named pipes. DCERPC Distributed Computing Environment / Remote Procedure Call (DCERPC) [OpGr01] is a generic protocol for the transmission of function calls on a remote computer. DCERPC can use different transport protocols. In Active Directory, TCP (ncacn_ip_tcp) and SMB named pipes (ncacn_np) are used as transport protocols. With DCERPC, related functions are combined into interfaces. These interfaces are specified using the Interface Definition Language (IDL) [OpGr03]. The transmission of the function parameters and return values ​​is implemented using the Network Data Representation (NDR) [OpGr02]. DCERPC takes care of the session management including authentication and optional encryption. With ncacn_ip_tcp, servers usually do not use fixed TCP ports. Instead, they register with the endpoint mapper (see [OpGr04]), where clients can then inquire about the TCP ports used. DCERPC-based interfaces / protocols A number of DCERPC-based protocols are used in Active Directory. However, the IDL specifications used by Microsoft are not published. The best public, but incomplete, IDL specifications for these protocols are maintained by the Samba team and a number of other volunteers (see [SaTe03]) SAMR The SAMR protocol provides functions for user and group management (see samr.idl under [SaTe03 ]). The name comes from the Security Account Manager (SAM) used under Windows NT 4.0. 4 SMB is also known as the Common Internet File System (CIFS).

21 Basic protocols NETLOGON The NETLOGON protocol provides functions for authentication within Windows domains. These functions are used, among other things, for NTLMSSP authentication. In addition, the NETLOGON interface provides functions for the SAM replication used under Windows NT 4.0 (see netlogon.idl under [SaTe03]) DRSUAPI The Directory Replication Service Update API (DRSUAPI) protocol offers functions for Active Directory replication can be used (see drsuapi.idl under [SaTe03]). In addition, the DsCrackNames () is offered, which converts the names of directory objects between different name formats.

22 Basic Concepts of the Replication System Basic Concepts of the Replication System Source-DSA vs. Destination-DSA During replication, changes to the database must be transferred from one server, the so-called Source-DSA, to another server, the so-called Destination-DSA. Replication vs. multimaster replication When it comes to replicating databases, a basic distinction is made between the single master and the multimaster model. Single-master replication With the relatively simple single-master replication, write access is only possible on one server and all other servers may only offer read access, since otherwise the data stock can become inconsistent. Multi-master replication With the more complex multi-master replication, write access is possible on all servers. Here, however, inconsistencies must be firmly anchored in the concept. Conflicts should therefore be resolved by algorithms so that each server can work independently. I. E. a conflict is resolved in the same way on each server so that the database becomes consistent again. In Active Directory, multimaster replication is used, although certain system-critical write operations are only allowed on one server for the FSMO role owner 6. Push replication vs. pull replication In general, when replicating databases, push replication and Differentiated pull replication. Push replication With push replication, the server on which the data was changed decides when and which data it has to send to its replication partner. In order to keep this system efficient, the source DSA must keep records of which data has already been transmitted for each destination DSA. However, due to connection interruptions or other errors it can happen that data does not arrive correctly at the destination DSA, but the source DSA assumes an error-free transmission. In this case, the Destination DSA will never receive some changes. Pull replication With pull replication, each server knows what data it has already received. The destination DSA tells the source DSA what data it already has for each replication request. The source DSA can then determine which data it must provide to the destination DSA so that the data on both servers match. This method is by far not as sensitive to transmission errors as push replication. The pull replication is typically triggered at configurable intervals, since the destination DSA does not know when changes are made to the source DSA

23 Basic Concepts of the Replication System 17 take place. In addition, a mechanism called change notify is often used. A source DSA sends change notifications to the destination DSA, which can then react with an immediate pull replication. In Active Directory, pull replication with change notifications is used. Log-based vs. status-based replication In order to make replication of data efficient, it is necessary to keep records of write accesses. There are also two approaches here, the log-based and the status-based. Log-based replication With log-based replication, every change is written to a log file. The advantage of this method is that every change can be traced and old states can be restored. However, the required storage space grows linearly with the number of changes and not with the size of the current database. Status-based replication The status-based replication takes a different approach, and only the current data is saved. A sequence number is used, which is incremented with every change. With every change the current sequence number is assigned to the changed data record. During replication, it is only necessary to know up to which sequence number has already been successfully transferred, then only data records with a higher sequence number have to be transferred. The storage space here is linear to the size of the current database.Active Directory uses status-based replication Store-and-Forward replication When replicating with many servers involved, it is desirable that not every server has to replicate with each other. The principle of store-and-forward replication enables changes to be transferred indirectly between two servers that do not have a direct network connection. The replication could look like this: Server A replicates with Server B, Server B replicates with Server C. With such a replication topology, changes on Server A are only replicated to Server B and from there to Server C. This topology can be expanded as required. Each server knows which changes it has already received from which other server. The way (directly or indirectly) in which the changes are transferred is irrelevant. The store-and-forward principle is used in Active Directory. The structure of the replication topology used (see [MSTN02]) is not dealt with in this bachelor thesis.

24 Basic Attributes and Structures Basic Attributes and Structures In order to describe the replication used in Active Directory, a number of basic attributes, structures and terms are required. These are briefly explained below. The objectguid attribute Since objects can be moved or renamed within a directory partition, the object DN is not always unique. Each directory object therefore has a so-called Global Unique Identifier (GUID) 5, which never changes. Roughly speaking, a GUID is a 128-bit (16-byte) random number. A GUID is partially described by an IDL structure (see Figure 3.6), the NDR coding of which is an array with 16 bytes. Often, however, a string representation is also used, e.g. B f1-eecc-47bf-ba c93e2e73. The GUID of the directory object is stored NDR-coded in the objectguid attribute. The objectsid attribute domains, user accounts and groups also have a security identifier (SID) 6, which is used for identification during the authorization check. The SID is described as struct dom_sid 7 in IDL (see Figure 3.6). Usually, however, the string representation is used, e.g. B. S used. The SID is made up of the domain SID and the relative identifier (RID) for the user or group. In the example, S is the domain SID and 1286 is the RID of the user. The SID of a directory object is stored NDR-coded in the objectsid attribute. The structure DsReplicaObjectIdentifier Within the DRSUAPI protocol, an object is referenced by a directory object identifier 8, which is made up of the object GUID, the object SID and the object DN composed. One of the three elements must always have a valid value, the other two are optional and can also be initialized with NULL bytes. 5 Although in German it should actually be called the GUID, the literature always speaks of a GUID. A GUID is also known as a Universal Unique Identifier (UUID). 6 Here, too, the literature speaks of a SID. 7 struct dom_sid2 and struct dom_sid28 differ slightly in the NDR coding. However, this difference can be neglected here. 8 For the most part, struct drsuapi_dsreplicaobjectidentifier is used (see Appendix A2 from line 128). However, there are also modifications, e.g. B. struct drsuapi_dsreplicaobjectidentifier3, which however only show differences at the NDR level.

25 Basic Attributes and Structures 19 Figure 3.6 The IDL Description of the Directory Object Identifier Basic Structures The NTDS Settings Object Each DSA saves its own configuration in an object of the ntdsdsa class and the RDN CN = NTDS Settings. An example object is shown in Figure 3.7. The objectguid and invocationid attributes are particularly relevant here. Both contain an NDR copied GUID. The so-called DSA-GUID, which uniquely represents the DSA and never changes, is stored in the objectguid attribute. The directory database currently used by DSA has its own GUID, the so-called DSA invocation ID, which is saved in the invocationid attribute. The DSA invocation ID is generated when the DSA is installed. When the DSA is installed first in the domain forest, the DSA-GUID and the DSA-Invocation-Id have identical values. Only in special cases, e.g. B. When restoring a backup, the DSA invocation ID is changed.

26 Basic Attributes and Structures 20 Figure 3.7 A typical NTDS Settings Object The highestcommitedusn attribute In Active Directory, a 64-bit (unsigned) Update Sequence Number (USN) is used, which is incremented with every write access. This USN is local to the respective DSA. Each DSA provides the currently highest USN in the attribute highestcommitedusn of the RootDSE (see Figure 3.2).

27 Basic attributes and structures The structures DsReplicaCursor and DsReplicaCursorCtr In order to implement the store-and-forward principle, every change process is clearly described in Active Directory by the DSA invocation ID and the associated USN. This data is transferred in the DRSUAPI protocol as struct drsuapi_dsreplicacursorctr, i. H. as an array with struct drsuapi_dsreplicacursor elements (see Figure 3.8). These structures are also available with an additional time stamp, which indicates the time of the last successful replication. struct drsuapi_dsreplicacursorctr is also called an Up-To-Date-Vector. Figure 3.8 The IDL description of the up-to-date vector basic structures The structure DsReplicaHighWaterMark In the case of direct replication between two servers, a so-called high water mark is exchanged. Figure 3.9 shows its structure. The high water mark contains the USNs already known to the Destination DSA from Source DSA. Figure 3.9 The IDL description of the high water mark structure.

28 Basic attributes and structures The repsfrom and repsto attributes The high water mark is stored in the repsfrom attribute, along with some other information on the associated DSA. For each source DSA from which it is replicated, there is a separate attribute value, which contains the NDR-coded form of struct repsfromtoblob (Figure 3.10). For each destination DSA that is to be informed of changes by means of a change notify, an attribute value of the repsto attribute is available analogously. The DSAs with which the local DSA replicates in any form are also called replication neighbors. Figure 3.10 The IDL description of the repsfromtoblob structure.

29 Basic attributes and structures 23 Figure 3.11 The bit flags DsReplicaNeighbourFlags ASN.1 Object Identifier Attributes and object classes are uniquely identified in the schema using an ASN.1 Object Identifier (OID), e. B (see [ITUT01]). The OID value is saved as an ASCII string in the Active Directory schema. The attributeid attribute is saved for attributes and the governsid attribute for classes. The OID has nothing to do with the DsReplicaObjectIdentifier structure! The prefix mapping Within the DRSUAPI protocol, attributes and object classes are not referenced by name, but by a 32-bit (unsigned) integer value. This 32-bit value is derived from the OID value. The OID string is separated into the prefix and the last element at the last occurrence of the character. (See Figure 3.12). Since the OIDs used in the schema mostly only differ in the last element, a table with so-called prefix mappings is used. Here the OID prefixes are mapped to 16-bit (unsigned) integer values. The 16-bit prefix is ​​written in the 16 most significant bits of the 32-bit value. The last element is also interpreted as a 16-bit (unsigned) integer value and written to the lower 16-bit of the 32-bit value. Figure 3.12 shows the list with the prefix mappings used in Active Directory. The 32-bit value is also referred to as AttId for attributes.

30 Basic Attributes and Structures 24 Figure 3.12 Example for the prefix mapping including the base table used in Active Directory.

31 Basic attributes and structures The structures DsReplicaOIDMapping and DsReplicaOIDMapping_Ctr Within the DRSUAPI protocol, the prefix mapping table is transferred as an array with struct drsuapi_dsreplicaoidmapping elements (see Figure 3.13). Figure 3.13 The IDL description of the prefix mapping basic structures Originating updates vs. replicating updates Changes that were generated by client applications, i.e. not caused by replication, are called originating updates. Replicated changes are referred to as replicating updates. The replpropertymetadata attribute The metadata required for replication are saved for each directory object in the replpropertymetadata attribute. Not all attributes are replicated in Active Directory, and some attributes are generated dynamically in the event of a search request. The attribute replpropertymetadata is a non-replicated attribute which only has a meaning for the local DSA. The content of this attribute is NDR-coded and described as struct replpropertymetadatablob in IDL (see Figure 3.14). The metadata for each replicated attribute is stored in an array of struct replpropertymetadata1 elements. Attributes are referenced via the 32-bit AttId. With each originating update of an attribute, the version field is incremented and the modification time, the DSA invocation ID and the USN (originating and local) are set. With a replicating update, all metadata elements, with the exception of the local USN, are transferred from the source DSA to the destination DSA as struct drsuapi_dsreplicametadatactr. The local USN is then added by the destination DSA when the replicated change is imported.

32 Basic Attributes and Structures 26 Figure 3.14 The IDL description of the replproperymetadata and DsReplicaMetaDataCtr basic structures The DsReplicaObject structure In the DRSUAPI protocol, directory objects are transferred as struct drsuapi_dsreplicaobject (see Figure 3.15). An object consists of a directory object identifier and an attribute array of struct drsuapi_dsreplicaattribute elements. Each attribute is referenced again via the AttId. In addition, each attribute has a value array made up of struct drsuapi_dsattributevalue elements. Each value consists of a byte array (DATA_BLOB).

33 Basic attributes and structures 27 Figure 3.15 The IDL description of the DsReplicaObject basic structures The list elements DsReplicaObjectListItem and DsReplicaObjectListItemEx In the DRSUAPI protocol, directory objects are transmitted as a single linked list. There are two variants here. Either the list elements contain only the struct drsuapi_dsreplicaobject or additionally the GUID of the parent object and a metadata array that has the same size as the attribute array, whereby the array elements with the same index also belong together ( see Figure 3.16). Figure 3.16 The IDL description of the DsReplicaObjectListItem and DsReplicaObjectListItemEx list elements.

34 Basic attributes and structures The usncreate and usnchanged attributes The usncreate and usnchanged attributes each contain the local USNs. usncreate is set when the directory object is created on the local DSA. usnchanged contains the USN of the last attribute change of the directory object. Analogous to the USN attributes, there are also the whencreated and whenchanged attributes, which contain time stamps in the form Z. The instancetype attribute The instancetype attribute contains bit flags linked by disjunction. Every directory object has this attribute. The INSTANCE_TYPE_WRITE bit flag is set for writable objects, and the root object of the root domain in the domain forest has also set the INSTANCE_TYPE_IS_NC_HEAD bit flag. All other root objects of a directory partition also have the bit flags INSTANCE_TYPE_IS_NC_HEAD and INSTANCE_TYPE_NC_HEAD_ABOVE set. Figure 3.17 shows all possible bit flags. Figure 3.17 The bit flags for the instance type attribute The system flags attribute The system flags attribute contains bit flags linked by disjunction. It is only available for system-critical directory objects, e.g. B. to prevent deletion. Figure 3.18 shows all possible bit flags. Figure 3.18 The bit flags for the system flags attribute.

35 Basic attributes and structures The msds-behavior-version attribute In order to incorporate new functions in Active Directory from release to release, Microsoft uses so-called function levels (see [MSTN06]). Domain controllers, domains and domain forests each have a function level assigned, which is saved in the msds-behavior-version attribute. Figure 3.19 shows the possible values. Figure 3.19 The possible values ​​for the msds-behavior-version attribute.

36 Originating updates Originating updates In order to implement the status-based store-and-forward replication used in Active Directory, a series of metadata must be maintained by the DSA. After all the required structures, terms and attributes have been explained, the handling of the metadata in the case of originating updates is analyzed. In general, changes in an originating update are validated using the directory scheme. If the domain forest is in function level DS_BEHAVIOR_2000, the smallest element to be replicated is an attribute including all of its attribute values. The function levels DS_BEHAVIOR_2003_INTERIM and DS_BEHAVIOR_2003 enable the independent replication of individual attribute values ​​if it is a so-called linked attribute. Linked attributes are not discussed in more detail here. Metadata storage with originating add When a new directory object is created, the attributes used for replication are automatically generated by the DSA. A new unique GUID is generated for the objectguid attribute. The instancetype attribute receives the value INSTANCE_TYPE_WRITE. In addition, the whencreated and whenchanged attributes are initialized with the current time stamp. The usncreated and usnchanged attributes are initialized with the USN assigned to the change. An attribute based on the RDN of the new object, e.g. B. dc or cn generated. In addition, the name attribute is added with the attribute value of the attribute based on the RDN. The replpropertymetadata attribute stores an array of metadata for each attribute 9 to be replicated (see Figure 3.14). The AttId is set based on the attribute name and the version element is initialized with 1. The current time stamp is stored in the originating_change_time element. The local DSA invocation ID is stored in the originating_invocation_id element. The USN assigned to the change is written to the originating_usn and local_usn elements. H. when an attribute is deleted, it is saved by an attribute with no attribute value. Before this, however, a check is made to see whether the attribute values ​​really change due to the change. If this is not the case, the attribute change is ignored. If all attribute changes are ignored, the entire change is ignored. If the change is not ignored, the whenchanged and usnchanged attributes are each set to the current time or USN. The metadata in the replpropertymetadata attribute is adapted for the changed or added attributes. The version element is incremented or initialized with 1 for added attributes. The elements originating_change_time, originating_invocation_id, originating_usn and local_usn are set in the same way as the originating add. 9 Some attributes are only relevant locally for the DSA, and some attributes are automatically constructed when a query is made