Brian Candler wrote:

Now, if my understanding of the user_realm parameter is correct, I think there are two ways to make OpenLDAP's behaviour consistent with its documentation.

(1) Stick more or less with the current behaviour, and change the documentation to say that you'll get uid=ursula/admin@foreign.realm,cn=gssapi,cn=auth for foreign realms.

However, the odd thing about the current behaviour is that setting olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into the auth DN, regardless of whether it's local or foreign. That's not very useful.

Note that it's not the OpenLDAP code that's sticking this in there; it's the Cyrus code that's returning this realm in the callback. IMO our job is to faithfully return what the Cyrus library gave us.

I think it would make more sense, if olcSaslRealm is present, to use it to *qualify* usernames which don't have a realm.

That decision is made by the Cyrus library, not us.

  uid=kurt,cn=gssapi,cn=auth

---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth

i.e. change the canonicalize function to append @user_realm if the username doesn't contain '@'.

This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of stripping off the default realm.

(2) Change the OpenLDAP behaviour so that it matches the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI

To do this, the canonicalize function would have to parse the username, splitting it on '@' to separate username from realm, so that you would get

 uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth

If the username doesn't contain '@', but olcSaslRealm is set, then I suggest you insert that instead:

 uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth

And if there's no '@' and no olcSaslRealm, then just leave it alone:

 uid=kurt,cn=gssapi,cn=auth

This has been discussed at great length, read the -devel archives from 9 or 10 years ago. The fact is that the SASL specification doesn't reserve '@' as a special character and there is no guarantee that this is actually a realm separator. There are plenty of authentication mechanisms where '@' is an integral part of the username. This suggestion simply won't fly.

I don't believe we have any freedom to make any code changes here; feel free to suggest verbiage changes for the documentation.