Skip to end of metadata
Go to start of metadata

UIB can treat an Active Directory (AD) server as a standard LDAP server because [UIB] only use a small subset of the functionality in LDAP.

Two AD or LDAP servers are supported. The primary server is checked first and if the user is found, authentication is attempted. If authentication fails, access is denied.
If the user is not found in the primary LDAP/AD server, authentication against the secondary LDAP/AD server is attempted.

It is possible to configure whether UIB can write or if the LDAP/AD server is read-only.

Single AD/LDAP with write permissions

This is the standard setup. AD integration is similar to LDAP, but the default schema in AD has no UID field. It is possible to add an extension (todo reference here) to AD to get UID and other LDAP fields, but otherwise UID is constructed from existing AD fields. I.e. Default AD configuration will work without any modifications.

Only AD read-only

NotApplicable / NotSupported, as it can't support a huge amount of Whydah functionality.

  • Functionality requiring write permissions to AD/LDAP
    • Add new users (new UserIdentity) (Create OAUTH2/Facebook/NetIQ user representations, sign-up functionality)
    • Update UserIdentity (update 2-factor cell-phone number, update name/surname)
    • New Password (lost password functionality)
AD + Whydah LDAP (AD or LDAP is master)
  • New users are added to master, but not to secondary
  • Master is used first, secondary thereafter
  • Write UserIdentity updates to both
AD read-only + Whydah LDAP (LDAP is master)
  • Use AD for auth
  • Fallback on LDAP for auth
  • Writes UserIdentity to LDAP
    • User may have two passwords if they use Whydah to change passowrd
  • Support usage during AD downtime/mainternance

Only AD - CLEANUP required

Works as standalone LDAP, with the following exception(s)

TODO: What rules defines the tranformation from an AD user to a Whydah user?

  • Import all
  • Whydah user = AD user
  • First access
  • Manual process?

Those decisions needs to be implemented to keep the UserDataIntex in Lucene "up-to-date"

Comments from ED to be merged into the text.
  • Default AD LDAP schema does not have an uid field. Extensions are possible to add this. If no uid can be found, UIB use the userprincipalname field as uid. Example:
  • Import functionality is used to add applications, organizations and mapping between roles and users. It is possible to add mapping to roles without actually importing any users by referencing the uid expected to be found when looking up the user in AD.
  • Login as usual with username without domain. E.g. erikd, not DOMAIN\erikd.
  • Authentication and authorization of users thus not rely on any changes to LDAP/AD servers, only the role database is changed.
  • NOTE! The lucene index is currently not updated on import. See todo in RoleMappingImporter. The UserAdminWebapp can thus not find the users, but they can login.


Mapping is performed in LdapUserIdentityDao.

UserIdentity field LDAP field LDAP schema AD field
uid uid core.schema userPrincipalName
username initials, non-standard use core.schema sAMAccountName
cn cn core.schema cn
sn sn core.schema sn
givenName givenName core.schema givenName
mail mail core.schema mail
mobile mobile cosine.schema mobile
userpassword, case error, should be userPassword? userPassword core.schema userPassword
personRef employeeNumber inetorgperson employeeNumber

See Table 8.3: Commonly Used Syntaxes for readable syntax descriptions.

Windows Active Directory LDAP Schema

Default AD LDAP schema does not have an uid field. Extensions (Microsoft’s Services for UNIX?) are possible to add this. If no uid can be found, UIB use the userprincipalname field as uid. Example:

Enter labels to add to this page:
Please wait 
Looking for a label? Just start typing.