RBAC User Synchronization with AD

This topic was edited by a BMC Contributor and has not been approved.  More information.

Introduction:

Customers that are using Domain Authentication or ADK Authentication methods in BMC Server Automation have an option to sync the BMC Server Automation users with the users in an Active Directory server programmatically. This enables customers to create the users in RBAC automatically by running the synchronization process. This feature is available only for users who are using AD authentication and not LDAP authentication. This is because the users that are created automatically in RBAC are enabled for AD authentication and no other authentication method.

This does not take away from the fact that the authentication configuration still needs to be done separately and in addition to any configuration done for LDAP synchronization.

This feature is available to synchronize users in two ways:

  • Synchronize users in a specific Base DN
    • This is only available through CLI and will synchronize users that are created within a certain base distinguished name such as an OU.
    • This is helpful if the customers want to bring in all the users from AD that are in a specific location in the LDAP tree and are not organized in groups. All these users will be created in RBAC and will be assigned the role that is synchronized
  • Synchronize users in a group
    • This is available both through CLI and UI
    • This is used when users are organized in groups within AD and customers want to sync AD groups to the RBAC roles in BMC Server Automation
    • This requires creation of group LDAP query and user LDAP query and role group mappings

Pre-requirements:

  • For LDAP sync to work, AD server must have a certificate installed and must have support for LDAP with startTLS extensions. This is because we only support secure connection with the AD server for communication. You can check whether the certificate is installed on the AD server by running the following commands on the application server, making sure that the second command lists the certificate successfully:

    blcred -x ADcert.p12 cert -add -host <your AD server IP>:389 -protocol ldap
    blcred -x ADcert.p12 cert -list
    
  • Credentials are available for at least one AD user who can browse the AD tree to view the users that need to be synced. Generally, any AD admin can do this.
  • Either a certificate of the AD server or of the CA server that issued the certificate for AD server must be available in a file format on the client machine. This will be needed to add into the LDAP connection. In general a pem file format is good that typically may have extensions like .cer, .crt or .cert.
  • At least one attribute for the user in AD must have the user name in the format of <user>@<domain>.com, where <user> is the user name and <domain> is the correct domain name of the user used for authentication.

Steps in the process:

  1. Create an Automation Principal:
    1. When defining an automation principal, the value you set for Principal ID must be a user’s distinguished name for a directory user that has at least read access on the users that you want to synchronize. For example, you might enter CN=Administrator,CN=Users,DC=company,DC=com
    2. During user synchronization, the Domain field of the automation principal is ignored and hence can be left blank.
    3. Password for this user must be specified in the passphrase and confirm fields
    4. To perform this from CLI, run the following command:

      Impersonation createAutomationPrincipal <Name> <Description> <Distinguished name of user> <Domain> <password for the user>
      

      For example,

      Impersonation createAutomationPrincipal ADSyncAdmin "Domain administrator to be used with AD Sync" “cn=administrator,cn=users,dc=sso,dc=bmc,dc=com” “” "p@$$w0rd“
      
  2. Create an LDAP connection:
    1. To set up an LDAP connection, you must have the host name or IP address of the AD server and a certificate that can be used to validate the certificate of AD server. This certificate is in the pem format. If you are using Microsoft CA issued certificate, instructions to request and install the certificate on the AD server can be found at http://support.microsoft.com/kb/321051:
    2. If the Verify host name when establishing a secure connection check box is selected, the system compares the host name included in the certificate that the AD server presents when Application Server connects with the AD server during synchronization to the host name specified in the URL of the AD server (provided on the Server field when creating the LDAP connection). Hence, if you are using IP address of the AD server, clear this check box (Caution: a more secure option is to verify the host name).
    3. Browse to the certificate file to add a certificate to the LDAP connection. This must either be the certificate of the AD server or of a CA server that issued the AD server’s certificate, preferably the latter in a pem formatted file (typically a .crt, .cer or .cert file).
    4. To perform this from CLI, run the following command:

      Ldap createConnection <Name> <Name of the ldap server> <Certificate file path> <Description>
      

      For example, below we create an LDAP connection with name SSO, server engw2k8x64sso8.sso.bmc.com, and trust store file C:\p4\8_0_security\om\test\conf\ldap_trust_store.crt.

      Ldap createConnection SSO engw2k8x64sso8.sso.bmc.com C:\p4\8_0_security\om\test\conf\ldap_trust_store.crt "SSO connection"
      

      Hostname Verification can be modified using following command:

      Ldap setHostnameVerification <name of the connection> true/false
      
  3. If using LDAP Sync to synchronize AD groups, skip to step 4. If using LDAP Sync to synchronize users in a specific Base DN, run the following blcli command as RBACAdmins or any other role that have permissions to read automation principal, read ldap connection, create users, read users, and modify the role that is synchronized. This will be the final step in such a case.

    RBACRole syncUsers <sync Option> <RoleName> <LDAP Connection> <Automation principal> <BASE DN> <Optional user Filter> <attribute>
    

    For example:

    RBACRole syncUsers ADSyncRole disableMissingUsers ADConnection ADAdmin “CN=Users,DC=sso,DC=bmc,DC=com” “(objectClass=user)” userPrincipalName
    

    Where:

    • <RoleName> : Role that is being synchronized
    • <sync Option>: An optional parameter to specify an action that must be performed on the users that are enabled for synchronization and exist in RBAC but do not come back in the result set of the LDAP query. If no action is needed to be performed on such users, this parameter should be omitted. Valid values for this parameter are -r, -e, -er, or -u. Full name of the option can also be specified instead of just switches. These are explained below
      • pruneMissingUsers | -r: Unassign the role that is synchronized from users that are not found in the result set of the LDAP query
      • disableMissingUsers | -e: disables users in RBAC that are not found in the result set of the LDAP query
      • disableAndPruneMissingUsers | -er| -re: performs both of the above operations
      • deleteMissingUsers | -u: deletes users from RBAC that are not found in the result set of the LDAP query
    • <LDAP Connection>: Name of the LDAP connection object that is to be used to determine which AD server to contact
    • <Automation principal>: Name of the Automation Principal object that defines the user credentials that are to be used to login to AD server
    • <BASE DN>: Base distinguished name from which to start searching for users.
    • <Optional user Filter>: This is an LDAP filter that can be specified to only select a filtered list of users
    • <attribute>: Contains the username in the format of <user>@<domain>.com, where <user> is the username and <domain> is the correct domain name of the user used for authentication. Typically, userPrincipalName attribute has the correct username.
  4. If using LDAP Sync to synchronize users in a specific AD group, you also create two LDAP queries.
    • One query specifies the group that needs to be synchronized and an attribute that lists all the members of that group (by default AD server uses the memberattribute to specify this). To do this from CLI, the following command can be used:

      Ldap createQuery <Name> < DN for the group> <ldap filter to be used if any> <Attribute that lists all members> <description>
      

      For example, the following query is for an AD group Domain Admins:

      Ldap createQuery DomainAdminsQuery “CN=Domain Admins,CN=Users,DC=sso,DC=bmc,DC=com” (objectClass=*) member “Domain Admins”
      
    • The second query is created to add a user filter and specify an attribute that contains the username in the format of <user>@<domain>.com, where <user> is the username and <domain> is the correct domain name of the user used for authentication. Typically, userPrincipalNameattribute has the correct username. To do this from CLI, the following command can be used:

      Ldap createQuery <Name> < DN if you want to constraint member users to this DN> <ldap filter to be used if any> <Attribute to get the username from> <description>
      

      For example:

      Ldap createQuery UsersQuery “” (objectClass=user) userPrincipalName “User ldap query”
      
  5. Edit the role that needs to be synchronized with an AD group and add group mapping specifying the automation principal, ldap connection, group ldap query, and user ldap query. Multiple group mappings can be specified if more than one group needs to be synchronized with the same role. Synchronizing the same role with AD groups in different AD servers is also supported via multiple group mappings specifying respective automation principal, ldap connection, group ldap query, and user ldap query. To do this from CLI, the following command can be used:

    RBACRole addLdapGroupMapping <Role Name> <LDAP Connection name> <Automation Principal Name> <Group Query Name> <User Query Name>
    

    For multiple group mappings, you can run this command multiple times with correct mappings

  6. Any options to manage the users that are synced can be specified on the same screen. These options are explained below:
    • Unassign the role that is being synchronized from users that are not found in the result set of the LDAP query
    • Disable users in RBAC that are not found in the result set of the LDAP query. This option can be selected in conjunction with the one above.
    • Delete users from RBAC that are not found in the result set of the LDAP query
      To set these options from command line, following command can be run:

      RBACRole setLdapSyncOptions <Role Name> <true/false for deleting missing users> <true/false for disabling missing users> <true/false for unassigning missing users>
      
  7. After saving the role, right click on the role and observe Synchronizemenu option should now be available. Clicking on which synchronizes prompts for confirmation and upon confirming runs synchronization in the background. To do this from CLI, use following command:

    RBACRole syncUsers <Role Name>
    
  8. Once synchronized, the users should be created, enabled for AD authentication, assigned the role that was synchronized, and enabled to participate in the AD sync process.

    Note

    User participates in directory synchronization flag on specific users can be used to determine and control whether a particular user should be impacted by user synchronization with AD server or not. Users created manually do not have this enabled by default, whereas users created via AD sync process have this enabled by default.

Was this page helpful? Yes No Submitting... Thank you

Comments