SiNotes-Grid

1.#ldapsearch -h localhost -p 389 -x -b "" -s base -LLL supportedSASLMechanisms
dn:
supportedSASLMechanisms: GSSAPI

*Because I have already disable other auth mechanisms when building Cyrus-SASL, only GSSAPI available here.

2.#ldapsearch -h localhost -p 389 -I -b "" -s base -LLL supportedSASLMechanisms
SASL/GSSAPI authentication started
SASL Interaction
Please enter your authorization name:
SASL username: ktang/admin@IERC.OX.AC.UK
SASL SSF: 56
SASL installing layers
dn:
supportedSASLMechanisms: GSSAPI

* Note*: Don't enter anything when promoted to enter username!!! just press "Enter"!
otherwise errors will occur:
ldap_sasl_interactive_bind_s: Insufficient access (50)
additional info: SASL(-14): authorization failure: Inappropriate authentication

*Of course you need to use "kinit ktang/admin" first to get the ticket.
Alternatively, you can use:
./ldapsearch -h localhost -p 389 -U 'ktang/admin@IERC.OX.AC.UK' -b "" -s base -LLL supportedSASLMechanisms
Then no need to input username.

3. Any user authenticaited by Kerberos will be mapped to an authentication request DN in LDAP server in form of :
uid=username,cn=realm,cn=gssapi,cn=auth

To check your authentication request DN, use "/usr/local/openLDAP/bin/ldapwhoami" command. In my case, I was authenciated as "ktang/admin@IERC.OX.AC.UK" in kerberos server, then my authentication request DN in LDAP is:
uid=ktang/admin,cn=ierc.ox.ac.uk,cn=gssapi,cn=auth

4. You can configure ACL in slapd.conf to give read/write access to the authentication request DN above, this might be the simplest way, for example, add following in slapd.conf will make I have write priviledge to all entries in LDAP server after I was authenticatied as ktang/admin by
kerberos:
access to *
by self write
by dn="uid=synew,cn=ierc.ox.ac.uk,cn=gssapi,cn=auth" write
by users read
by anonymous auth
by * none
However, usually we already has all entries for all the users who wanna access it in Ldap server,
but not in the authencation request format(e.g. not under auth subtree ). What we need is authentication identities mapping.

5. Wherever possbile, direct mapping is recommanded,which has the following format:
authz-regexp
uid=([^,]*),cn=oerc.ox.ac.uk,cn=gssapi,cn=auth
uid=$1,dc=oerc,dc=ox,dc=ac,dc=uk

*N.B. Don't use the following format, it doesn't work for me, although it should.
authz-regexp
uid=([^,]*),cn=[^,]*,cn=auth
uid=$1,dc=oerc,dc=ox,dc=ac,dc=uk

*N.B. With this mapping added, the ACL we just made will *NOT* work for the super user "synew"!! The reason is your authencation quest DN is no longer "uid=synew,cn=ierc.ox.ac.uk,cn=gssapi,cn=auth", but is
mapped to "uid=synew,dc=oerc,dc=ox,dc=ac,dc=uk" !!! Therefore we need to use the following
ACL policy instead:
access to *
by self write
by dn="uid=synew,dc=oerc,dc=ox,dc=ac,dc=uk" write
by users read
by anonymous auth
by * none

posted by Synew  # 4:45 AM