Re: Preauth error ldap heimdal kerberos

[Buchan Milne <bgmilne@staff.telkomsa.net>]

On Wednesday, 24 March 2010 11:04:57 Μανόλης Βλαχάκης wrote:
> 2010/3/24 Buchan Milne <bgmilne@staff.telkomsa.net>
> 
> > On Tuesday, 23 March 2010 11:18:57 Μανόλης Βλαχάκης wrote:
> > > after reading the openldap admin guide you mentioned
> > > i understud that by using -X on the ldapsearch command
> > > i should use the authzTo attribus as you said
> >
> > But, you haven't explained if or why you need to authorize to different
> > users.
> > IMHO, it looks plainly as if you have been using the -X flag by mistake
> > ...
> >
> > The document you referred to doesn't use -X anywhere, only -x in the case
> > of
> > simple binds.
> >
> > I want to do sasl bind not simple bind that's why i use the -X flag! Am i
> 
> wrong?

Yes. -x is for simple binds. Without -x, you get SASL binds (it is the 
default, if your software is compiled with SASL support). -X is not for 
forcing SASL, but for something a bit more obscure than what I think you want 
...

Here are some examples from a working OpenLDAP/Heimdal setup:

As a unix user:

Simple bind:

[bgmilne@tiger ~]$ ldapwhoami -x -D 
uid=bgmilne,ou=people,dc=ranger,dc=dnsalias,dc=com -W
Enter LDAP Password:
dn:uid=bgmilne,ou=People,dc=ranger,dc=dnsalias,dc=com


[bgmilne@tiger ~]$ kinit
bgmilne@RANGER.DNSALIAS.COM's Password:
[bgmilne@tiger ~]$ klist
Credentials cache: FILE:/tmp/krb5cc_501
        Principal: bgmilne@RANGER.DNSALIAS.COM

  Issued           Expires          Principal
Mar 24 12:30:43  Mar 24 19:10:43  
krbtgt/RANGER.DNSALIAS.COM@RANGER.DNSALIAS.COM


SASL/GSSAPI:

[bgmilne@tiger ~]$ ldapwhoami
SASL/GSSAPI authentication started
SASL username: bgmilne@RANGER.DNSALIAS.COM
SASL SSF: 56
SASL data security layer installed.
dn:uid=bgmilne,ou=people,dc=ranger,dc=dnsalias,dc=com
[bgmilne@tiger ~]$ klist
Credentials cache: FILE:/tmp/krb5cc_501
        Principal: bgmilne@RANGER.DNSALIAS.COM

  Issued           Expires          Principal
Mar 24 12:30:43  Mar 24 19:10:43  
krbtgt/RANGER.DNSALIAS.COM@RANGER.DNSALIAS.COM
Mar 24 12:30:50  Mar 24 19:10:43  
ldap/tiger.ranger.dnsalias.com@RANGER.DNSALIAS.COM


Simple, anonymous:

[bgmilne@tiger ~]$ ldapwhoami -x
anonymous


SASL/EXTERNAL on ldapi

[bgmilne@tiger ~]$ ldapwhoami -x -H ldapi:/// -Y EXTERNAL
ldapwhoami: incompatible with authentication choice
[bgmilne@tiger ~]$ ldapwhoami -H ldapi:/// -Y EXTERNAL
SASL/EXTERNAL authentication started
SASL username: gidNumber=501+uidNumber=501,cn=peercred,cn=external,cn=auth
SASL SSF: 0
anonymous


As root:

For KDC's access to LDAP:

[root@tiger ~]# cat .ldaprc
SASL_MECH EXTERNAL
URI ldapi:///
[root@tiger ~]# ldapwhoami
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn:uid=account admin,ou=system accounts,dc=ranger,dc=dnsalias,dc=com


For nss_ldap etc. to enumerate users (e.g., would be identical on client-only 
hosts), so that proxy users are not required, and access is host-specific with 
no clear-text credentials on clients:


[root@tiger ~]# klist
Credentials cache: FILE:/tmp/krb5cc_0
        Principal: host/tiger.ranger.dnsalias.com@RANGER.DNSALIAS.COM

  Issued           Expires          Principal
Mar 24 12:22:01  Mar 24 19:02:01  
krbtgt/RANGER.DNSALIAS.COM@RANGER.DNSALIAS.COM
Mar 24 12:33:51  Mar 24 19:02:01  
ldap/tiger.ranger.dnsalias.com@RANGER.DNSALIAS.COM

[root@tiger ~]# ldapwhoami -Y GSSAPI
SASL/GSSAPI authentication started
SASL username: host/tiger.ranger.dnsalias.com@RANGER.DNSALIAS.COM
SASL SSF: 56
SASL data security layer installed.
dn:uid=host/tiger.ranger.dnsalias.com,ou=people,dc=ranger,dc=dnsalias,dc=com


> what are you suggesting to do with the users? I believe that there is not
> need to have
> all users authoirized but only two for example only these who i have in
> kerberos
> ldapmaste and kadmin/admin! am i right?

I don't know what you are trying to achieve.

> Take a look to my slapd.conf!

It's pointless without knowing what you are trying to achieve.

> My problem, is that i  want to do sasl bind with password and not only with
> dn because now i do sasl bind only with one of the authorized dn!

If you have Kerberos, why do you want to provide a password? You should 
instead be happy with a SASL GSSAPI bind, which is authenticated (but, not by 
password transfer in clear text to slapd).


Regards,
Buchan