As an alternative to the SQL database backing store, the Identity Service can use a directory server to provide the Identity Service, for example: dn: dc=AcmeExample,dc=org dc: AcmeExample objectClass: dcObject objectClass: organizationalUnit ou: AcmeExample dn: ou=Groups,dc=AcmeExample,dc=org objectClass: top objectClass: organizationalUnit ou: groups dn: ou=Users,dc=AcmeExample,dc=org objectClass: top objectClass: organizationalUnit ou: users dn: ou=Roles,dc=AcmeExample,dc=org objectClass: top objectClass: organizationalUnit ou: roles The corresponding entries in the keystone.conf configuration file are: [ldap] url = ldap://localhost user = dc=Manager,dc=AcmeExample,dc=org password = badpassword suffix = dc=AcmeExample,dc=org use_dumb_member = False allow_subtree_delete = False user_tree_dn = ou=Users,dc=AcmeExample,dc=com user_objectclass = inetOrgPerson tenant_tree_dn = ou=Groups,dc=AcmeExample,dc=com tenant_objectclass = groupOfNames role_tree_dn = ou=Roles,dc=AcmeExample,dc=com role_objectclass = organizationalRole The default object classes and attributes are intentionally simple. They reflect the common standard objects according to the LDAP RFCs. However, in a live deployment, you can override the correct attributes to support a preexisting, complex schema. For example, in the user object, the objectClass posixAccount from RFC2307 is very common. If this is the underlying objectclass, then the uid field should probably be uidNumber and username field either uid or cn. To change these two fields, the corresponding entries in the Keystone configuration file are: [ldap] user_id_attribute = uidNumber user_name_attribute = cn Depending on your deployment, you can modify a set of allowed actions for each object type. For example, you might set the following options: [ldap] user_allow_create = False user_allow_update = False user_allow_delete = False tenant_allow_create = True tenant_allow_update = True tenant_allow_delete = True role_allow_create = True role_allow_update = True role_allow_delete = True If the back-end provides too much output, you can filter users, tenants, and roles. For example: [ldap] user_filter = (memberof=CN=acme-users,OU=workgroups,DC=AcmeExample,DC=com) tenant_filter = role_filter = If the directory server has not enabled the boolean type for the user, you can use configuration options to extract the value from an integer attribute. For example, in an Active Directory, as follows: [ldap] user_enabled_attribute = userAccountControl user_enabled_mask = 2 user_enabled_default = 512 The attribute is an integer. Bit 1 contains the enabled attribute. If the user_enabled_mask mask is not 0, it gets its value from the user_enabled_attribute field and it performs an ADD operation by using the user_enabled_mask value. If the value matches the mask, the account is disabled. It also saves the value without mask to the identity user in the enabled_nomask attribute. In case you must change it to enable or disable a user, you can use this value because it contains more information than the status such as, password expiration. The user_enabled_mask value is required to create a default value on the integer attribute (512 = NORMAL ACCOUNT on AD). If Active Directory classes and attributes do not match the specified classes in the LDAP module, so you can modify them, as follows: [ldap] user_objectclass = person user_id_attribute = cn user_name_attribute = cn user_mail_attribute = mail user_enabled_attribute = userAccountControl user_enabled_mask = 2 user_enabled_default = 512 user_attribute_ignore = tenant_id,tenants tenant_objectclass = groupOfNames tenant_id_attribute = cn tenant_member_attribute = member tenant_name_attribute = ou tenant_desc_attribute = description tenant_enabled_attribute = extensionName tenant_attribute_ignore = role_objectclass = organizationalRole role_id_attribute = cn role_name_attribute = ou role_member_attribute = roleOccupant role_attribute_ignore =