Is there way to use objectGuid instead of dn in API ?

We have an application which use ldap protocol. We use unboundId library for that

// ldap
implementation("com.unboundid:unboundid-ldapsdk:6.0.9")

We found out that most api calls use dn as argument.

For example:

ldapConnectionPool.getEntry(dn)

But we also found out that dn is not immutable identifier (it could be changed if we move the object from one location to another one or if we rename it (change CN) but it is not good to have mutable identifiers for many reasons. So we started to look for immutable identifier and found out objectGuid.

But the problem here that I can't find any method which allow me to :

Get entry by objectGuid

I've found only this way but I am not sure about performance:

SearchRequest searchRequest = new SearchRequest(
                searchBase, 
                SearchScope.SUB, 
                Filter.createEqualityFilter("objectGuid", objectGuid)
        );

Extract objectGuid from creation request:

    LDAPResult addResult = ldapConnectionPool.add(addRequest)

So my question is:

Is it a good idea to use objectGuid as identifier in our application or not ? performance matters.

From the first glance it looks really attractive but looks like library is not designed for that. What do you think ?

The objectGUID attribute is something that is proprietary to Active Directory, although standard LDAP has something similar that accomplishes the same purpose (the entryUUID attribute, as described in RFC 4530), so it's disappointing that Active Directory doesn't support that instead or as an alternative.

The LDAP SDK doesn't provide any specific support for objectGUID, meaning that it doesn't have any specific support for retrieving its value or converting between its different representations. If you need to do that, then you'll have to provide your own code for it or find it elsewhere.

Immutable attributes like entryUUID and objectGUID are most commonly used for synchronizing data between systems rather than being used directly by regular applications, and most regular applications just use DNs to identify entries. An entry's DN shouldn't change unless you explicitly change it with a modify DN, and it's extremely unlikely that one client will change an entry's DN while another is in the course of performing a sequence of operations involving that entry.

To be honest, both objectGUID and entryUUID are very user-unfriendly, and DNs aren't much better. If you need to interact with an entry, the best course of action is generally to search for it using something that is more user-friendly (e.g., an email address, username, or name for a person) to get its DN, and then if you need to perform more operations on that entry (e.g., to authenticate as that user or modify the entry), then you'd use the DN. As I previously stated, it's extremely unlikely that an entry's DN will change when you're performing multiple operations against an entry in quick succession.

On top of that, LDAP operations typically identify entries by their DNs. The LDAP protocol specification in RFC 4511 specifically states that when binding to a server using simple authentication, the user is identified by the "name" field in the bind request, and that field is defined as being a DN. So while Active Directory might support authenticating with something that isn't a DN, that's actually a violation of the protocol. Again, that's unfortunate because LDAP does provide standard ways to authenticate a user without needing them to identify them by DN (most SASL mechanisms allow you provide an alternative identifier, which could be something like a username or email address or potentially even a GUID), so Microsoft really didn't need to do their own thing that explicitly makes their communication incompatible with the protocol specification when there are standards-compliant ways of achieving the same result.

Ultimately, the LDAP SDK doesn't explicitly verify that the value you provide as the bind DN when attempting simple authentication is actually a valid DN, so you could probably authenticate with the string representation of an objectGUID value as the bind DN if you really wanted to, but as I said before, it's not necessary, not user-friendly, and because it's a nonstandard behavior that violates the protocol, it could lock you into a particular server implementation (which is, of course, why Microsoft loves doing stuff like that instead of abiding by standards and common industry practices).

pingidentity / ldapsdk

Is there way to use objectGuid instead of dn in API ? #148