ADSynch Light: Case Study 2

 

Case Study – Using ADAM and ADSynch Light

About Active Directory in Application Mode (ADAM)

Microsoft offers „Active Directory in Application Mode” (ADAM), a free LDAP service, which is very close in specification to Active Directory, the major BackOffice LDAP data store used in any Windows 2000+ domain network. This LDAP directory is a standalone service, complying with public standards, yet being similar to Active Directory itself it provides a well known, tested at length and secure structure and interface for storing hierarchical information. Providing similar functionality and for it specific bindProxy object type is additionally delivers the ideal solution for mirroring information from other LDAP sources, providing transparent single sign on as an added bonus.

ADAM can be downloaded for free at http://www.microsoft.com/adam. The current version (by date of 21.06.2007) can be run as a service on any Windows XP Clients or Windows Server.

About ADSynch Light (the predecessor of LDAPSync)

ADSynch Light is a lightweight LDAP based directory synchronization service. It allows for synchronizing any type of LDAP data store including Active Directory, ADAM, openLDAP, Exchange 5.5, SunONE, … Setup and Configuration is GUI based and a large range of build in functions and configurable business rules allow for defining any type of synchronization required. It specifically allows for easy implementation of individual synchronization settings, delivering manageable service delivery other synchronization services cannot provide.

ADSynch Light is tremendously important to reduce administrative efforts and service cost in any situation where more than one LDAP directory data store is required. Data has not to be managed at more than one place, single sign on will become possible even for legacy applications.

ADSynch Light is available at our download section – including a free test version upon request. ADSynch Light is sold as a business service, and we are guaranteeing you exactly that support which you require to implement the synchronization solution you require.

 

Case Study – Using ADAM and ADSynch Light to create transparent application specific LDAP directories, reusing Active Directory data and credentials

Introduction

The CWARE system requires user account related information stored in Active Directory to perform system related account administration tasks. To store the required information the system need an Active Directory schema extension to the user account object and the group object as defined in the standard Active Directory schema. In many cases this is not tolerated in the customer’s active directory organization, either for security, data ownership related or just plain effort related reasons.

Risks and problems when using Active Directory as data store

Active Directory is the basis for many network operating system related components and back office services in any IT network based on Windows 2000 (or higher) infrastructure. Active Directory delivers the central data store – it is the core of your back office which, when not organized well and when corrupted will negatively influence service which keep your network infrastructure running – up to the point of a complete failure or all back office service.

Microsoft Active Directory is a LDAP standard based data store, which stores information in an object-properties related structure. To enable solution providers to take advantage of the always present information store, the option to extend the schema allows for placing additional object and attribute definition into the schema – to extend the Active Directory schema. The schema, though, is critical because of the following reasons:

  • „ The schema is central to any Active Directory domains, meaning for all network components and service which are connected into the domain structure.
  • „ It is enforced upon any object, taking effect immediately
  • „ Changes cannot be undone easily, nor changes made in fault.

The entire domain structure withing a single Active Directory forest share the same schema

Schema

 

As with some companies the Active Directory sometimes hold many million objects and their attributes, these organizations are hesitating to any changes to the core schema as they might affect the overall structure in terms of data structure, security, size, replication issues and administration efforts.

As described above the is an entire list of reasons why one should refer from using Active Directory itself as a data store for application specific data:

  • „ The Active Directory is a core infrastructure service – it is critical to many BackOffice and network services where tempering could introduce severe operational risks
  • „ As a central service it should only hold central information that must be accessible from every service, not application specific data.
  • „ Active Directory, though implementing most LDAP standards sometimes cannot be used directly from legacy LDAP services or from applications that heavily rely on these standards. E.g.: many applications written for openLDAP, … can either not directly use some of the features of Active Directory or cannot access (and manage) data at all.

Side effects from implementing additional LDAP services

  • „ If implementing any LDAP service you might have to manage your users, user related information and access rights individually, introducing unneeded extra administrative efforts and cost.
  • „ By using other LDAP service your users and/or the LDAP based service will have to maintain additional password for accessing the extra LDAP server, bearing the additional security risks and password management efforts.

Ideal Solution

Even without extending the Active Directory Schema, the required information can be stored and accessed by CWARE. By creating a suitable schema in ADAM, using the proxyUser object class functionality („Bind-Redirection”) CWARE can store its required data in ADAM, make use of the same user credentials already in place within the company’s Active Directory. By implementing a directory synchronization service using ADSynch Light, all required Active Directory data is made available for the LDAP service within ADAM and kept up to date. Administration of general and BackOffice information is performed with the user administration process in place – CWARE only accesses and manages its own required data without interfering.

Speicherung der Daten in im Schema vorhandenen Objekten und Eigenschaften

The default template schema extension for MS_User_Proxy contains already all information required to use ADAM build in „Bind-Redirection” functionality, enabling users to login to ADAM using their Active Directory stored user credentials.

In the case of CWARE the following additional information must be made available:

  • „ Is the CWARE User a „Administrator”
  • „ Is the CWARE User a „SuperUser”
  • „ Is the CWARE User a „SecurityUser”
  • „ Is the User a CWARE User at all
  • „ Which is the standard role for the CWARE User

ADAM – Application-specific LDAP Directory

When you cannot make use of Active Directory you might to implement an additional LDAP directory, like in the case of CWARE where the CWARE service has been built around different LDAP access / connection functions than those available with Active Directory. In the case of CWARE though, existing Windows user information must also be available and is read and used by the CWARE service. With such a constellation (application specific LDAP data store / required standard user information) the ideal solution is to rollout the additional LDAP service and synchronizing it with existing data, so no added administrative tasks are required. Making use of ADAM lies at hand at the CWARE makes use of LDAP interfaces.

Implementing ADAM

ADAM can be obtained from Microsoft for free at http://www.microsoft.com/adam. Die current version (21.June.2007) enables easy deployment on Windows XP Clients or Windows Server systems.

Installation

For installation of ADAM, execute Setup.exe and follow the instructions. After successful installation you will find the following entries in the start menu:

ADAM works as a system service and will install a new service for every “LDAP server” instance you deploy. To create a new instance click „Create an ADAM instance”.

ADAM provides many functions already know by Windows Active Directory, e.g.: replication to other LDAP server instances to create a high availability LDAP service. When another service has been installed already you can define the replication partners with whilst installing the second partner. We will not make use of this feature in this case study.

In the current settings we create a single new instance, so we select „A unique instance”.

Every ADAM LDAP server service is identified using a unique name. This name is the one used to name the system service on the local machine, e.g.: to stop the service, for event log entries, …

For listening to LDAP request, ADAM will install a listener for every LDAP server instance and required defining the ports used to listen and to access the LDAP service. Note: To access the LDAP service from other machine you might need to open the firewall on the port defined here.

To enable storing application specific data, you will need to create an application partition in the directory (This is equivalent to defining a root folder in a directory). This can be performed by the installation process already, so you will not have to create the application partition afterwards.

You will also need to define the location for the LDAP service database files. These are the files you need to backup to enable restore of the LDAP service in the case of system failures.

If required you can define a system account to run the service.

For every new LDAP service instance you need to define the user account that will be assigned as administrator of the LDAP server. This enables access to the service after installation. After installation you define additional accounts and change security settings.

ADAM itself is an „empty” LDAP directory, only providing definitions for classes and attributes it requires for itself. To store you own data you will need to define you own schema classes and attributes or to import templates. The installation program allows for importing some standard templates already whilst installing. As CWARE requires classes and attributes common in Active Directory but also the „Bind-Redirection” functionality, i.e.: accessing ADAM with Active Directory credentials, we will import the template for „MS_User_Proxy”. Other templates can be imported after installation using LDIF files.

After installation the service itself can be managed in the service manager console:

 

Konfiguration

To access and manage data within the LDAP service, you also find a start menu entry pointing to „ADAM ADSI Edit”. This is a limited LDAP Browser you can use to create objects and manage attributes. Also you can view and manage the ADAM schema and extend it.

The schema we have imported (MS_User_Proxy) does not have any definitions for classes and attributes required for CWARE. We now have to configure those:

  • „ Open ADAM ADSI Ed it
  • „ After ADAM ADSI Edit has been loaded, click on the list entry “ADAM ADSI Edit” using the right mouse button and select „Connect to…”
  • „ Enter the connection details for the LDAP Server instance („localhost” and Port)
  • „ Click OK
  • „ Expand the new entry in the list and select the container „cn=Schema, cn=configuration, …” – You will see all existing schema class and schema attribute definitions

 

Importing the schema extension for CWARE

The required CWARE attributes can either be added manually using ADAM ADSI Edit, or by importing an LDIF file. Importing an LDIF file will tremendously improve quality of the extending the schema, as you can eliminate errors in a test environment and import the „clean” template in a productive situation. In our case we have designed the schema extension in a test environment and exported the LDIF file for the required classes and attribute. To import these do the following:

  • „ Locate the file „CWARE ADAM Schemaextension.ldf”
  • „ Open the ADAM Command Prompt (found in the Start Menu à ADAM)
  • „ Execute the following command:
    ldifde-i-ffilename-scomputername:port [-busernamedomainpassword] -k-j.-c”CN=Schema,CN=Configuration,DC=X”#schemaNamingContext -z

    Do not change the entries in bold
    Filename is the file name of the schema extension
    You can enter a user name and password if required
  • „ After importing the schema extension you can review and check it using ADAM ADSI Edit (The attributesCWAREAdministrator, CWARESuperUser, CWARESecurityUser, defaultRole, CWAREUserAttr, uid, sAMAccoutName, mail, givenName, sn, and the class User must now be present in the list.

Note: When extending the schema it can be the case that ADAM reports errors as the linking of the new attributes cannot be performed. The reason is that ADAM does not recognize the new attribute quick enough. In this case, please stop and restart the LDAP service after importing the schema extension, and re-import the same extension again.

  • „ After completing the schema extension, restart the LDAP service using the service manager.
  • „ View and check the extended class and attributes using ADAM ADSI Edit. You might have to select „Update Schema Now” by clicking the root entry of the schema, thereby refreshing the display.

 

Creating containers for storing objects

CWARE requires a few containers – this again could be created manually, though, we have prepared another LDIF file for data quality reasons in the production environment. CWARE requires a container with the name “roles” – as there is an original container with the same name already, it must be renamed before importing the LDIF files for the new containers:

  • „ Select the Container cn=Roles using ADAM ADSI Edit
  • „ Using the right mouse button select à Rename à Enter „RolesOriginal” à Press ENTER
  • „ Locate the Import file „CWARE ADAM Container Import.ldf”
  • „ Perform the same steps as with the schema extension:
  • o Open ADAM Command Prompt (Start Menu à ADAM)
  • o Execute:
    ldifde-i-ffilename-scomputername:port [-busernamedomainpassword] -k-j.-c”DC=test,DC=com”„[NameOfYourApplicationPartition]” -z

    Do not change entries in bold
    Filename is the name of the container import file
    NameOfYourApplicationPartition is the name of the partition that you created whilst installing the LDAP server instance, e.g.: dc=CWARE,dc=com
    You can optionally provide user credentials
  • o After refreshing you should see all of the required containers and organizationalUnit objects: „ou=Roles”, „ou=Groups”, „ou=Accounts” and „cn=User”.

Enabling Bind-Redirection

After installing ADAM and implementing the schema extension „MS_User_Proxy” you can connect to ADAM using a proxy object. This object will redirect the binding to the Active Directory account defined in its attributes. Normally this is only enabled for SSL connections – in our case SSL is not an options and the security risks with using non SSL connections are low. To enable bind redirection for non SSL connection we have to change the following setting:

  • „ Connect to the configuration partition of your LDAP server instance using ADAM ADSI Edit
  • „ Select the object „Directory Service” with the path Configuration/Services/Windows NT, and view its properties (right mouse click – properties)
  • „ Change the settings for the attribute msDS-Other-Settings by changing the value for RequireSecureProxyBind from 1 to 0. Do this by selecting the value, clicking Remove, changing 1 to 0 and clicking Add.

 

Implementing the synchronization between Active Directory and ADAM using ADSynch Light

To make user data from Active Directory accessible in ADAM, these have to be synchronized from Active Directory to ADAM. We will implements this service using ADSynch Light by UID Systems as it can meet all the specific requirements in this setup easily and can be configure nicely using the GUI within a short time. Also it enables extensive testing and debugging of our settings before deployment.

Especially useful is the option to store the successfully tested configuration in a template file for deployment in the productive environment.

Advantages using ADSynch Light:

  • „ All required attributes get filled when new users are created (Default Values). The rule to always deploy a default CWARE role can be met and all CWARE attributes be filled
  • „ All CWARE Roles are managed in Active Directory as group objects will be synchronized including their membership.
  • „ Data will stay up-to-date. This in addition to using the binding redirection, the LDAP server is completely transparent towards CWARE. The CWARE service will use ADAM like it is an openLDAP implementation, though always having Active Directory data present and using Active Directory credentials.
  • „ After defining the requirements – the entire configuration process took 30 minutes, including all special rules and non standard attribute mapping like sAMAccountNameàUID, replicating the Active Directory objectSID into the proxy user object, and defining group member replication.

Deployment

  • „ Install ADSynch Light on the ADAM Server
  • „ Save the template file in a location of your choice (The same folder will also be used to store a log file folder when running the synchronization)
  • „ Open the configuration file using ADSynch Light
  • „ Change connection settings and other configuration parameters if required (For support contact support@uidsystems.com)
  • „ Test-Run – View the action in detail as they would be performed. If everything is according to your requirements and no error have occurred you can continue.
  • „ Production Run – All objects are now present in ADAM – Users can now connect to the CWARE service using their Active Directory credentials.
  • „ Use the task scheduler to schedule a synchronization task every 30 minutes.

 


 

Appendix 1: CWARE ADAM Schemaextension.ldf

dn: CN=mail,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: mail

distinguishedName:

CN=mail,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.11

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: mail

oMSyntax: 20

lDAPDisplayName: mail

name: mail

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=givenName,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: givenName

distinguishedName:

CN=givenName,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.9

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: givenName

oMSyntax: 20

lDAPDisplayName: givenName

name: givenName

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=sn,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: sn

distinguishedName:

CN=sn,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.8

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: sn

oMSyntax: 20

lDAPDisplayName: sn

name: sn

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=sAMAccountName,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: sAMAccountName

distinguishedName:

CN=sAMAccountName,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.7

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: sAMAccountName

oMSyntax: 20

lDAPDisplayName: sAMAccountName

name: sAMAccountName

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=uid,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: uid

distinguishedName:

CN=uid,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.6

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: uid

oMSyntax: 20

lDAPDisplayName: uid

name: uid

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=CWAREUserAttr,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: CWAREUserAttr

distinguishedName:

CN=CWAREUserAttr,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.4

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: CWAREUserAttr

oMSyntax: 20

lDAPDisplayName: CWAREUserAttr

name: CWAREUserAttr

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=defaultRole,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: defaultRole

distinguishedName:

CN=defaultRole,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.3

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: defaultRole

oMSyntax: 20

lDAPDisplayName: defaultRole

name: defaultRole

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=efpAdminUser,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: efpAdminUser

distinguishedName:

CN=efpAdminUser,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.0

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: efpAdminUser

oMSyntax: 20

lDAPDisplayName: efpAdminUser

name: efpAdminUser

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=efpSecurityUser,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: efpSecurityUser

distinguishedName:

CN=efpSecurityUser,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.1

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: efpSecurityUser

oMSyntax: 20

lDAPDisplayName: efpSecurityUser

name: efpSecurityUser

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=efpSuperUser,CN=Schema,CN=Configuration,DC=X

changetype: add

objectClass: top

objectClass: attributeSchema

cn: efpSuperUser

distinguishedName:

CN=efpSuperUser,CN=Schema,CN=Configuration,DC=X

instanceType: 4

attributeID: 1.3.6.1.4.1.4268.200.2.1.2

attributeSyntax: 2.5.5.4

isSingleValued: TRUE

showInAdvancedViewOnly: TRUE

adminDisplayName: efpSuperUser

oMSyntax: 20

lDAPDisplayName: efpSuperUser

name: efpSuperUser

objectCategory:

CN=Attribute-Schema,CN=Schema,CN=Configuration,DC=X

 

dn: CN=User,CN=Schema,cn=configuration,dc=x

changetype: add

objectClass: top

objectClass: classSchema

cn: User

distinguishedName: CN=User,CN=Schema,cn=configuration,dc=x

instanceType: 4

possSuperiors: domainDNS

possSuperiors: organizationalUnit

possSuperiors: container

possSuperiors: organization

subClassOf: top

governsID: 1.3.6.1.4.1.4268.200.2.1.10

mayContain: sn

mayContain: givenName

mayContain: samAccountName

mayContain: uid

mayContain: efpSuperUser

mayContain: efpSecurityUser

mayContain: efpAdminUser

mayContain: defaultRole

mayContain: CWAREUserAttr

mayContain: mail

rDNAttID: cn

showInAdvancedViewOnly: TRUE

adminDisplayName: User

adminDescription: CWARE User Class.

objectClassCategory: 1

lDAPDisplayName: user

name: User

systemOnly: FALSE

systemMayContain: userPrincipalName

systemAuxiliaryClass: msDS-BindProxy

defaultHidingValue: TRUE

objectCategory: CN=Class-Schema,CN=Schema,cn=configuration,dc=x

defaultObjectCategory: CN=User,CN=Schema,cn=configuration,dc=x

 


Appendix 2: CWARE ADAM Container Import.ldf

dn: CN=Users,DC=test,DC=com

changetype: add

objectClass: top

objectClass: container

cn: Users

distinguishedName: CN=Users,DC=X

instanceType: 4

name: Users

 

dn: OU=Roles,DC=test,DC=com

changetype: add

objectClass: top

objectClass: organizationalUnit

ou: Roles

distinguishedName: OU=Roles,DC=X

instanceType: 4

name: Roles

 

dn: OU=Accounts,DC=test,DC=com

changetype: add

objectClass: top

objectClass: organizationalUnit

ou: Accounts

distinguishedName: OU=Accounts,DC=X

instanceType: 4

name: Accounts

 

dn: OU=Groups,DC=test,DC=com

changetype: add

objectClass: top

objectClass: organizationalUnit

ou: Groups

distinguishedName: OU=Groups,DC=X

instanceType: 4

name: Groups

 


Appendix 3 – ADSynch Light configuration report

Synchronisation-Project: CWARE Synchronization

PathC:UsersTestDesktop

CreateProjectFoldertrue

NameCWARE Synchronization

DescriptionSynchronizes User objects and groups (Roles) from Active Directory to ADAM for CWARE.

List of synchronisation tasks in project:

Synchronisation: USERS

Version1.6.0.0

ApplicationADSynchLight

GroupNameSynchronization

NameUSERS

Enabledtrue

SynchronisationTypeFullSynch

UpdateModeAll

DirectoryDeltaSynchronizationFieldNamehighestCommittedUSN

ObjectDeltaSynchronizationFieldNameusnChanged

CommitChangestrue

DescriptionSynchronize AD User to ADAM

Verbosetrue

LogFilePathlogs

LogFileNameLOG

KeepLogInDays20

highestCommittedUSNFileNameUSERS-lastUSN.txt

LimitUpdates0

LimitDeletionPercentage1

uniqueIDSynchronization-USERS

uniqueIDField

UseUniqueIDForObjectIdentificationDoNotUse

OnlySendReportOnChangesDoNotSendReports

SourceConnection ActiveDirectory Secure test.com DC=test,DC=com administrator

SourceLDAPCondition(&(objectcategory=person)(!(|(cn=administrator)(cn=gast)(cn=guest))))

SourceObjectClassuser

SourceSearchScopeSubtree

FieldMappings:

DestinationFieldcn

SourceValuecn

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFielddisplayname

SourceValuedisplayName

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldgivenname

SourceValuegivenName

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldsn

SourceValuesn

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldsamaccountname

SourceValuesamAccountName

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFielduid

SourceValuesamAccountName

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFielduserprincipalname

SourceValueuserprincipalName

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldcwareuserattr

SourceValuetrue

MappingTypeVBScript

UpdateTypeOnlySetWhenCreatingNewObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldefpadminuser

SourceValuefalse

MappingTypeVBScript

UpdateTypeOnlySetWhenCreatingNewObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldefpsuperuser

SourceValuefalse

MappingTypeVBScript

UpdateTypeOnlySetWhenCreatingNewObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldefpsecurityuser

SourceValuefalse

MappingTypeVBScript

UpdateTypeOnlySetWhenCreatingNewObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFielddefaultrole

SourceValue“TestRolle”

MappingTypeVBScript

UpdateTypeOnlySetWhenCreatingNewObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldobjectsid

SourceValueobjectsid

MappingTypeDirect

UpdateTypeOnlySetWhenCreatingNewObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldmail

SourceValuemail

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


ObjectUniqueIdentifyingAttributeMapping cn cn Direct user user cn cn Direct contact user cn cn Direct group user

MapFieldCN

DestinationConnection ActiveDirectory Secure dc=test,dc=com localhost:50004 cn=users,dc=test,dc=com administrator

DestObjectClassuser

DestObjectCategoryRDNQualifierCN

DestObjectCategoryRDNAttributeNameCN

DestAdditionalServerToCheckForMailAddresses

DestSynchInfoFieldDescription

Synchronisation: GROUPS

Version1.6.0.0

ApplicationADSynchLight

GroupNameSynchronization

NameGROUPS

Enabledtrue

SynchronisationTypeFullSynch

UpdateModeAll

DirectoryDeltaSynchronizationFieldNamehighestCommittedUSN

ObjectDeltaSynchronizationFieldNameusnChanged

CommitChangestrue

DescriptionSynchronize cware roles from AD to ADAM

Verbosetrue

LogFilePathlogs

LogFileNameLOG

KeepLogInDays20

highestCommittedUSNFileNameGROUPS-lastDeltaSyncID.txt

LimitUpdates0

LimitDeletionPercentage1

uniqueIDSynchronization-GROUPS

uniqueIDField

UseUniqueIDForObjectIdentificationDoNotUse

OnlySendReportOnChangesDoNotSendReports

SourceConnection ActiveDirectory Secure test.com OU=Roles,DC=test,DC=com administrator

SourceLDAPCondition(objectcategory=group)

SourceObjectClassgroup

SourceSearchScopeSubtree

FieldMappings:

DestinationFieldcn

SourceValuecn

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFielddisplayname

SourceValuedisplayName

MappingTypeVBScript

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredfalse

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite;

UniquenessOfAttributeValueNoUniquenessRequired


DestinationFieldmember

SourceValuemember

MappingTypeDirect

UpdateTypeSetWhenCreatingNewAndWhenUpdatingExistingObjects

ValueDNResolvingRequiredtrue

MultiValueSingularityNoUniquenessRequired

MultiValueBehaviorOverWrite

UniquenessOfAttributeValueNoUniquenessRequired


ObjectUniqueIdentifyingAttributeMapping cn cn Direct user user cn cn Direct group group cn cn Direct contact contact cn cn Direct publicfolder publicfolder

DestinationConnection ActiveDirectory Secure dc=test,dc=com localhost:50004 ou=Roles,dc=test,dc=com administrator

DestObjectClassgroup

DestObjectCategoryRDNQualifierCN

DestObjectCategoryRDNAttributeNameCN

DestAdditionalServerToCheckForMailAddresses

DestSynchInfoFieldDescription

Run History