Grizzly: new config file fields for LDAP
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
openstack-manuals |
Fix Released
|
Medium
|
Anne Gentle |
Bug Description
If https:/
new config options in keystone.conf
119 # user_enabled_
120 # user_enabled_mask = 0
121 # user_enabled_
878
879
880 There is a set of allowed actions per object type that you can modify
881 depending on your specific deployment. For example, the users are managed by
882 another tool and you have only read access, in such case the configuration
883 is::
884
885 [ldap]
886 user_allow_create = False
887 user_allow_update = False
888 user_allow_delete = False
889
890 tenant_allow_create = True
891 tenant_allow_update = True
892 tenant_allow_delete = True
893
894 role_allow_create = True
895 role_allow_update = True
896 role_allow_delete = True
897
898 There are some configuration options for filtering users, tenants and roles,
899 if the backend is providing too much output, in such case the configuration
900 will look like::
901
902 [ldap]
903 user_filter = (memberof=
904 tenant_filter =
905 role_filter =
906
907 In case that the directory server does not have an attribute enabled of type
908 boolean for the user, there is several configuration parameters that can be used
909 to extract the value from an integer attribute like in Active Directory::
910
911 [ldap]
912 user_enabled_
913 user_enabled_mask = 2
914 user_enabled_
915
916 In this case the attribute is an integer and the enabled attribute is listed
917 in bit 1, so the if the mask configured *user_enabled_mask* is different from 0,
918 it gets the value from the field *user_enabled_
919 operation with the value indicated on *user_enabled_mask* and if the value matches
920 the mask then the account is disabled.
921
922 It also saves the value without mask to the user identity in the attribute
923 *enabled_nomask*. This is needed in order to set it back in case that we need to
924 change it to enable/disable a user because it contains more information than the
925 status like password expiration. Last setting *user_enabled_mask* is needed in order
926 to create a default value on the integer attribute (512 = NORMAL ACCOUNT on AD)
927
928 In case of Active Directory the classes and attributes could not match the
929 specified classes in the LDAP module so you can configure them like::
930
931 [ldap]
932 user_objectclass = person
933 user_id_attribute = cn
934 user_name_attribute = cn
935 user_mail_attribute = mail
936 user_enabled_
937 user_enabled_mask = 2
938 user_enabled_
939 user_attribute_
940 tenant_objectclass = groupOfNames
941 tenant_id_attribute = cn
942 tenant_
943 tenant_
944 tenant_
945 tenant_
946 tenant_
947 role_objectclass = organizationalRole
948 role_id_attribute = cn
949 role_name_attribute = ou
950 role_member_
951 role_attribute_
Changed in openstack-manuals: | |
milestone: | none → grizzly |
tags: | added: keystone |
Changed in openstack-manuals: | |
assignee: | nobody → Anne Gentle (annegentle) |
patch was merged