LDAP: how to reference to another entry

Sometimes a set of yes/no values is stored in a single value by setting various bits. You can use a bitmask to check if they are set.

For example, 546 in decimal is the binary value 10 0010 0010 - in decimal, the sum of 512, 32, and 2. (All those numbers are powers of 2, which means they only have one '1' in their binary representation): That means those three yes/no values are set.

According to the userAccountControl docs that means the following values are set:

NORMAL_ACCOUNT (512)
PASSWD_NOTREQD (32)
ACCOUNTDISABLE (2)

However, for example, if you had a user who did not have PASSWD_NOTREQD set (so their userAccountControl value was 512), or one who also had DONT_EXPIRE_PASSWORD (65536) set (meaning their value was 66082), you would not find those users in your query.

What you need to do is use a bitwise AND in order to query the value of only that bit:

10 0010 0010
00 0000 0010
------------
00 0000 0010

If the value for that bit is 1, then that bit is set. It doesn't matter what the other bits are set to, so you are effectively asking if userAccountControl & 2 == 2.

The LDAP syntax for checking a bit using AND is 1.2.840.113556.1.4.803, therefore you can see if the ACCOUNTDISABLE bit is set with (userAccountControl:1.2.840.113556.1.4.803:=2). Adding (!(foo)) around it gives you all the users who are not disabled.

What objectClass is used for service identities?

Whatever you want, really. In order for Crowd (or anything else) to authenticate, you need a distinguished name somewhere in your tree and it needs to have a userPassword attribute.

If you look at your schema (if you're using OpenLDAP, that's usually /etc/openldap/schema), you can find objectClasses that meet this criteria.

The simplest is probably the person object class, the definition for which looks like this:

objectclass ( 2.5.6.6 NAME 'person'
        DESC 'RFC2256: a person'
        SUP top STRUCTURAL
        MUST ( sn $ cn )
        MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

That says that it requires the sn and cn attributes, and may optionally have a userPassword attribute (as well as a few others). So maybe you would add an entry like this:

dn: cn=crowd,ou=serviceAccounts, o=myOrganization
objectClass: person
cn: crowd
sn: Service Account
description: Service account for Crowd access to LDAP
userPassword: {SSHA}MZO/eoDUg/nFJDAZBvawCRYIxSeQUm3U

This presumes that you have a serviceAccounts OU where you will place this sort of thing, which is probably a good idea (because this clearly separates service accounts from user accounts).

Crowd would authenticate as cn=crowd,ou=serviceAccountrs,o=myOrganization, and you would need to configure your LDAP directory to give this DN the appopriate access permissions.