The Domain Server supports 2 primary security models, native and LDAP.
In native security, the users and groups are defined to the Domain Server itself as well as the relationships between the two.
With LDAP, users and groups are managed in the Domain Server, but the user credentials and groups associations are managed by LDAP. LDAP includes Microsoft Active Directory which supports LDAP connectivity. LDAP users can be defined manually or automatically when the user first logs in. Groups can be defined manually or imported from the LDAP server but must exist in the Domain Server to be used. One or more LDAP servers must be defined at the Domain Server and the appropriate credentials to query the LDAP servers provided.
When defined manually, you can assign the user to native groups or use LDAP groups which are mapped at login.
The process starts when a user, 'bob', logs in to any AutoPilot Service that uses the Domain Server, such as the Enterprise Manager, the web console, Navigator Classic (apodwmq), Navigator or various utilities. The login request is sent to the Domain Server which looks into the user database. If the user is there, the type of user will be determined.
If native, the credentials will be checked against the local definition and the groups assigned.
If the user is an LDAP user, the credentials are passed to the LDAP server for verification and group association is done.
If the user is not found, and if auto-creation is active (server.domain.ldap.auto.create=true), the Domain Server will assume the user is defined in LDAP and will create a dynamic entry for them. The user can be seen in User Manager marked as auto generated.
If set to do authentication only (server.domain.ldap.ldapserver.authenticateonly=true), no additional information is obtained from LDAP and only existing explicit AutoPilot group assignments are used. Otherwise, the associated groups for that user are queried from LDAP. That is, 'bob' could be part of the LDAP groups APADMINS, TEST1, DEVGROUP and UNIXADMIN. These groups are then matched to the AutoPilot Groups and any that match are dynamically assigned to 'bob'. If AutoPilot has groups ADMINS, APADMINS and DEVGROUP defined, than 'bob' would be part of APADMINS and DEVGROUP with associated rights and privileges. It is possible for 'bob' to login and belong to no groups and only able to see public AutoPilot data.
If 'bob' was logging on to a Web Security Manager (WSM) supported product, such as Navigator, an additional set of checking is done. WSM also supports manual and automatic user creation. If only manual (+u3) definition is active, 'bob' will be checked in defined users and if doesn't exist, will not be permitted to log on. If automatic user creation is active (+au) 'bob' will be added as a generated user and checking will continue.
For both manual and generated users, only groups defined in WSM will be assigned to 'bob'. If WSM had PRODGROUP and DEVGROUP groups defined, 'bob' would be assigned to the 'DEVGROUP' with the associated rights and privileges. If 'bob' is not part of any groups, they would not be permitted to log on since the connect right is not given.
LDAP group hierarchy example:
'bob'
LDAP: APADMINS, TEST1, DEVGROUP, UNIXADMIN
AutoPilot: ADMINS , APADMINS , DEVGROUP
WSM: PRODGROUP, DEVGROUP
For additional troubleshooting, see:
2.4.2 Configuring Domain Server for LDAP in the Autopilot M6 Administration Guide
AutoPilot Authentication Basics
AutoPilot Authentication Groups
How to troubleshoot Domain Server LDAP Security Integration