Please help us by completing this surveyGo to survey
At many companies users, groups and organization structure is stored and maintained in Active Directory - or in another storage, synced to AD. This is why sensenet is capable of synchronizing AD objects into both directions:
Changes are updated with batch synchronization meaning that all changes are synchronized periodically in one step performed by a standalone application.
Some other Active Directory related features include the following:
By setting up Active Directory synchronization users gain the following advantages:
Synchronization affects the following types of objects:
|AD object||sensenet Content Repository object|
|user||User (or a derived type)|
|Organization (only with eDir to Portal sync)||Organizational Unit|
Mapping of objects is configured by the definition of so-called sync-trees. A sync-tree defines the root element of the tree of synchronized objects both on the portal and in the AD. This means that whole object trees can be easily synchronized by simply defining the root element of the tree and the mapping of this root element to the portal / to the AD. Every object under the sync-tree root is mapped with respect to the mapping of the root objects. In order to customize which objects should be synchronized under in a sync-tree exceptions can be configured.
Different sync-trees may be defined on different servers and under different domains. This means that it is possible to sync objects from different domain controllers to the portal and to different domain controllers from the portal. Please note that the current implementation handles separate domains with the following restrictions:
The synchronization of objects is based on the objects’ objectGuid property in AD (the corresponding property of portal objects is called syncGuid). This means that whenever an object is updated the corresponding object to be updated is found by searching for the object having the same guid:
When a new object is created the objectGuid property of the AD object is copied into the syncGuid field of the portal object. In the Portal to AD direction the creation of a portal object triggers a creation of an AD object: the created AD object’s objectGuid is copied back to the portal object’s syncGuid.
The portal objects that are synchronized contain another property: LastSync. This date property shows the time of the last synchronization. This date is primarily used in AD to portal user and group synchronization: only those users’ and groups’ properties are synced that have been modified since the last synchronization (either in AD or in the portal). Note that moving objects in AD is always updated on the portal regardless of this property. Also note that moving objects on the portal will not update this property in the current implementation.
Syncing of users includes the following:
Syncing of groups includes the following:
Syncing of folders includes the following:
There is a way to authenticate users against an Active Directory even when using Forms authentication (instead of using Windows Integrated authentication). This means that when a portal user logs in with Forms authentication, his/her password is checked against the user’s password set in an Active Directory server and not against the one given on the portal.
This feature is not yet supported in sensenet 7.
The settings for forms authentication from AD be found in the
sensenet/formsAuthenticationFromAD section of the web.config. Below you can see a fully featured skeleton of this configuration:
<sensenet> <formsAuthenticationFromAD> <authSettings> <authSetting domain="" adServer="" virtualADUser="" customLoginProperty="" customADAdminAccountName="" customADAdminAccountPwd="" /> </authSettings> </formsAuthenticationFromAD> </sensenet>
You will also have to enable the AD DirectoryProvider in the web.config appsettings:
<add key="DirectoryProvider" value="SenseNet.DirectoryServices.ADProvider" />
The following settings can be customized using the
<authSetting> node above:
/Root/IMS/BuiltIn/Portal/VirtualADUser) and user properties are synced instantaneously in-memory (but no user is created on the portal).
The following xml is a simple example for setting up forms authentication from AD for a specific domain:
<sensenet> <formsAuthenticationFromAD> <authSettings> <authSetting domain="NATIV" adServer="188.8.131.52" /> </authSettings> </formsAuthenticationFromAD> </sensenet>
Every initiated action is logged in the system. Should an error occur during an action the execution will not hang instead the error is logged and the execution proceeds to the next action. Every single action and error is timestamped. In case of Portal to AD sync there is a possibility to redo/retry an unsuccessfully executed action.
A log file with a time stamp in its name is created next to the executor every time a synchronization is performed.
A daily logfile (rolling, max size is 200kB) is created in the web folder:
A typical log file may have a content similar to the following:
2010.10.11. 16:04:48 Start Start: SyncAD2Portal, id: 54667c38-c2c2-49cd-95ee-ba076547b8a2, method:Void Main(System.String), ticks:53542326027 2010.10.11. 16:04:48 Information Cacheing portal users... 2010.10.11. 16:04:49 Information Cacheing portal groups... 2010.10.11. 16:04:49 Information Cacheing portal containers... 2010.10.11. 16:04:49 Information Syncing containers (domains, orgunits, containers) (OU=MyOrg,DC=Nativ,DC=local --> /Root/IMS/NATIV/MyOrg) 2010.10.11. 16:04:49 Verbose Syncing (AD object: LDAP://184.108.40.206/OU=MyOrg,DC=Nativ,DC=local) 2010.10.11. 16:04:49 Verbose New portal domain - creating under /Root/IMS (AD object: LDAP://220.127.116.11/DC=Nativ,DC=local) 2010.10.11. 16:04:49 Verbose Updating portal domain properties (AD object: LDAP://18.104.22.168/DC=Nativ,DC=local; portal object: /Root/IMS/a9bed9ad-1218-4ae5-b578-83c310f19fb5) 2010.10.11. 16:04:49 Verbose New portal orgunit - creating under /Root/IMS/NATIV (AD object: LDAP://22.214.171.124/OU=MyOrg,DC=Nativ,DC=local)
Is something missing? See something that needs fixing? Propose a change here.