Differences
This shows you the differences between two versions of the page.
Next revision | Previous revisionNext revisionBoth sides next revision | ||
72:ldap_optional_attributes [2018/07/16 13:40] – created bkkr | 72:ldap_optional_attributes [2018/11/08 09:14] – [Optional Attributes] etea | ||
---|---|---|---|
Line 41: | Line 41: | ||
The syntax used to build up the filter expression is specified in RFC 2254. Some examples are provided below: | The syntax used to build up the filter expression is specified in RFC 2254. Some examples are provided below: | ||
- | ^Filter Expression ^Meaning | | + | ^Filter Expression^Meaning| | | |
- | |(objectClass=*) |All objects | | + | |(objectClass=*)|All objects| | | |
- | |(sn=sm*) |All entries with a surname that starts with " | + | |(sn=sm*)|All entries with a surname that starts with " |
- | |(&(sn=smith)(objectClass=user)(email=*)) |All entries that are users having the surname " | + | |(& |
- | |(&(objectClass=user)(!age< | + | |(& |
- | **NOTE**: In the PKitConfig.xml file the character “&“ has to be escaped via “& | + | **NOTE**: In the <font inherit/ |
- | There is a special memberOf keyword available on many LDAP directory servers. In the case of Microsoft Active Directory, groups are represented via entries of object class “group“ by default. The distinguished names of the group members are set in the member attributes of the group entry. On the other hand, the distinguished name of every group a user is part of is automatically set in a memberOf attribute of the user entry. | + | There is a special memberOf keyword available on many LDAP directory servers. In the case of Microsoft Active Directory, groups are represented via entries of object class “group“ by default. The distinguished names of the group members are set in the member attributes of the group entry. On the other hand, the distinguished name of every group a user is part of is automatically set in a <font inherit/ |
The following search filter example shows how to filter users according to a certain group membership using the memberOf attribute: | The following search filter example shows how to filter users according to a certain group membership using the memberOf attribute: | ||
- | searchFilter=" | + | ''< |
If the memberOf attribute is not available on your LDAP directory server, it is possible to retrieve the members of a certain group by querying the member attribute of a group entry. | If the memberOf attribute is not available on your LDAP directory server, it is possible to retrieve the members of a certain group by querying the member attribute of a group entry. | ||
- | The following search filter example shows how to query the users of a group without using the memberOf attribute: | + | The following search filter example shows how to query the users of a group without using the <font inherit/ |
- | searchFilter=" | + | ''< |
- | The filter specifies that the distinguished name of the (group) entry has to be “CN=SomeGroup, | + | The filter specifies that the distinguished name of the (group) entry has to be <font inherit/ |
- | A complete example for retrieving group members without using the memberOf attribute is listed below. | + | A complete example for retrieving group members without using the <font inherit/ |
- | searchFilter=" | + | ''< |
- | groupMemberAttribute=„member“ | + | groupMemberAttribute="member“</ |
- | === The ondemandFilter Attribute | + | === |
- | This attribute is required for user auto-creation and/or on-demand synchronization mode. It allows the Stages system to query the LDAP server for specific users by their Stages login name. The attribute value a query filter like the searchFilter attribute, except that it is meant for unique queries. | + | \\ |
- | The ondemandFilter must contain the placeholder character “%” that will be replaced by the username when queries on the LDAP repository are made. | ||
- | |||
- | Example: ondemandFilter=“(sAMAccountName=%, | ||
- | |||
- | === The matchUsersMode Attribute === | ||
- | |||
- | The matchUserMode attribute specifies how LDAP user entries are matched to Stages users when no mapping can be performed using the special _KEY attribute. | ||
- | |||
- | Possible values for the matchUserMode attribute are: | ||
- | |||
- | * username | ||
- | * fullname | ||
- | |||
- | |||
- | If no explicit value is set for that attribute then the username will be used for that purpose. | ||
- | |||
- | === The adoptUsers attribute === | ||
- | |||
- | Stages distinguishes between local user accounts and LDAP user accounts in its user database. The adoptUsers attribute can be used to convert a local user account to an LDAP account if the user can be identified via the matchUserMode attribute. To enable the user account conversion the adoptUser attribute has to be set to “true“. The conversion is disabled by default. | ||
- | |||
- | === The generateDN attribute === | ||
- | |||
- | If the directory server does not provide a distinguished name attribute for its entries, the generateDn attribute can be set to “true“ to calculate the distinguished name automatically. | ||
- | |||
- | === The defaultLicenseType attribute === | ||
- | |||
- | The defaultLicenseType attribute specifies which license type shall be granted to a newly created LDAP user. Possible values for that attribute are: | ||
- | |||
- | * QM | ||
- | * PM | ||
- | * Dev | ||
- | * none | ||
- | |||
- | The specified license type is only assigned if the corresponding license limit for that type is not reached. If the defaultLicenseType attribute is not specified then the value of the configuration property license.types.initialType is used for that purpose. | ||
- | |||
- | \\ | ||