GSSAPI Kerberos Directory Server 5.2
Hi
My first Thread about problems with GSSAPI, Kerberos and DS 5.2 is http://forum.sun.com/jive/thread.jspa?forumID=13&threadID=94693
now im very close to the end (i hope...)
I've got 3 sun stations sso1 (ds 5.2 & kerberos client), sso2 (kdc & ldapclient), test (kerberos & ldapclient)
my test user is "vinci". i can log in to ds with this user! i did everything like it is doumented in suns documentation and in the blueprint book...
if i do at the test machine (kerberos and ldap client installed):
get the ticket:
bash-3.00$ kinit
Passwordfor vinci@HTA.FHZ.CH:
bash-3.00$ klist
Ticket cache: FILE:/tmp/krb5cc_111
Default principal: vinci@HTA.FHZ.CH
Valid startingExpiresService principal
05/19/06 16:50:31 05/20/06 00:50:31 krbtgt/HTA.FHZ.CH@HTA.FHZ.CH
renew until 05/26/06 16:50:31
do an ldap-request with gssapi and get an error :-(
bash-3.00$ ldapsearch -h sso1.hta.fhz.ch -p 389 -o mech=GSSAPI -b"" -s base"(ob-jectclass=*)"
Please enter your authorization name:vinci
ldap_sasl_interactive_bind_s: Invalid credentials
ldap_sasl_interactive_bind_s: additional info: SASL(-1): generic failure: GSSAPI Er-ror: Unspecified GSS failure. Minor code may provide more information (No error)
in the log file from the kdc (/var/krb/kdc.log) at sso2 i see:
May 19 16:51:23 sso2.hta.fhz.ch krb5kdc[299](info): TGS_REQ 147.88.97.3(0): ISSUE: au-thtime 1148050231, vinci@HTA.FHZ.CHfor ldap/sso1.hta.fhz.ch@HTA.FHZ.CH
the log file from the ds (var/mps/serverroot/slapd-sso/log/access) shows:
[19/May/2006:16:54:38 +0200] conn=71 op=-1 msgId=-1 - fd=35 slot=35 LDAP connection from 147.88.97.3 to 147.88.97.11
[19/May/2006:16:54:40 +0200] conn=71 op=0 msgId=1 - BIND dn="" method=sasl version=3 mech=GSSAPI
[19/May/2006:16:54:40 +0200] conn=71 op=0 msgId=1 - RESULT err=49 tag=97 nentries=0 etime=0
[19/May/2006:16:54:40 +0200] conn=71 op=1 msgId=2 - UNBIND
[19/May/2006:16:54:40 +0200] conn=71 op=1 msgId=-1 - closing - U1
[19/May/2006:16:54:41 +0200] conn=71 op=-1 msgId=-1 - closed.
and if i now list my tickets at the test-machine:
bash-3.00$ klist
Ticket cache: FILE:/tmp/krb5cc_111
Default principal: vinci@HTA.FHZ.CH
Valid startingExpiresService principal
05/19/06 16:54:32 05/20/06 00:54:32 krbtgt/HTA.FHZ.CH@HTA.FHZ.CH
renew until 05/26/06 16:54:32
05/19/06 16:54:41 05/20/06 00:54:32 ldap/sso1.hta.fhz.ch@HTA.FHZ.CH
renew until 05/26/06 16:54:32
so the ds gets the ticket for the ldap service from kerberos... the mapping file is configured that it maps the principal to the user id... so if the principals name and the user name are the same (here vinci) it should work... my mapping file :
dn: cn=GSSAPI,cn=identity mapping,cn=config
objectclass: nsContainer
objectclass: top
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: nsContainer
objectclass: top
cn:default
dsMappedDN: uid=${Principal},ou=people,dc=hta,dc=fhz,dc=ch
dn: cn=HTA.FHZ.CH,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: HTA.FHZ.CH
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@HTA.FHZ.CH
dsMappedDN: uid=$1,people,dc=hta,dc=fhz,dc=ch
and the /etc/gss/mech file on kerberos (sso2):
kerberos_v5 1.2.840.113554.1.2.2mech_krb5.so kmech_krb5
spnego1.3.6.1.5.5.2mech_spnego.so.1 [msinterop]
diffie_hellman_640_01.3.6.4.1.42.2.26.2.4dh640-0.so.1
diffie_hellman_1024_01.3.6.4.1.42.2.26.2.5dh1024-0.so.1
dns is not really working but we modified the host-files so the 3 sun-station now each other...
please help me...
# 1
In the ldap entry representing your user profile, is the DN:
'uid=vinci,people,dc=hta,dc=fhz,dc=ch' ?
Looking at your GSSAPI mappings, this should be the dn that get's searched for.
Also, in your ldapsearch command, you are not specifying a base, have you tried -b 'dc=hta,dc=fhz,dc=ch'.
Also, have you tried making your default GSSAPI mappings match the configuration of your 'cn=HTA.FHZ.CH,cn=GSSAPI,cn=identity mapping,cn=config' entry? This might help for testing purposes.
Cheers,
Rob Chevalier
# 2
hi rob, thank u very much for ur effort!
we will do so, but (perhaps) its an other problem, what do you think. you know, we had to setup kerberos to. the tgt is running, and we can get our tickets for every host. now we tried to install / setup a simple kerberized rlogin, but we had some problems
http://forum.sun.com/jive/thread.jspa?threadID=94910
could this be the problem? we (described in the post) did all the steps in the sun tutorial. do u know, whats difficult concerning kerberized rlogin? do we have to start some services or such things, which weren't described @sun tutorial?
we don't see through :-(
nice wishes from switzerland.
roman & silvan.
# 3
Hey Rob
Thanks for the answer...
> In the ldap entry representing your user profile, is
> the DN:
> 'uid=vinci,people,dc=hta,dc=fhz,dc=ch' ?
yes
> Looking at your GSSAPI mappings, this should be the
> dn that get's searched for.
>
> Also, in your ldapsearch command, you are not
> specifying a base, have you tried -b
> 'dc=hta,dc=fhz,dc=ch'.
The Following example should answer the last 3 questions... i dont need a base here and the DN also works...
# ldapsearch -h sso1.hta.fhz.ch -p 389 -D "uid=vinci,ou=people,dc=hta,dc=fhz,dc=ch" -b "" -s base "(objectclass=*)"
Enter bind password:
version: 1
dn:
objectClass: top
namingContexts: dc=example, dc=com
namingContexts: dc=hta,dc=fhz,dc=ch
> Also, have you tried making your default GSSAPI
> mappings match the configuration of your
> 'cn=HTA.FHZ.CH,cn=GSSAPI,cn=identity
> mapping,cn=config' entry? This might help for
> testing purposes.
no i didnt try that yet... i will do so tomorrow and write i will back asap.
i also tried to make the maping directly to the DN "vinci ...." like this:
cn: default
dsMappedDN: uid=vinci,ou=people,dc=hta,dc=fhz,dc=ch
but it didnt work... (of course i tested this one just for the user vinci ;-)
cheer roman
# 4
i tried now also to make the default mapping match the configuration of the HTA.FHZ.CH mapping. So the mapping file was the following:
dn: cn=GSSAPI,cn=identity mapping,cn=config
objectclass: nsContainer
objectclass: top
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: default
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@HTA.FHZ.CH
dsMappedDN: uid=$1,people,dc=hta,dc=fhz,dc=ch
dn: cn=HTA.FHZ.CH,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: HTA.FHZ.CH
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@HTA.FHZ.CH
dsMappedDN: uid=$1,people,dc=hta,dc=fhz,dc=ch
i tried also the thing with the search base "-b "dc=hta,dc=fhz,dc=ch" but it has no effect!
when i do the following without gssapi it works...:
# ldapsearch -h sso1.hta.fhz.ch -p 389 -D "uid=vinci,ou=people,dc=hta,dc=fhz,dc=ch" -b "" -s base "(objectclass=*)"
Enter bind password:
version: 1
dn:
objectClass: top
namingContexts: dc=example, dc=com
namingContexts: dc=hta,dc=fhz,dc=ch
namingContexts: o=NetscapeRoot
hope i get some more help...
by the way rob: i should have anyway a little description your person because we will mention your name in our documentation... you can send it in a mail to "icpeter@hta.fhz.ch" thanks
# 5
Hi,
The dsMappedDN values are not valid DNs for both the cn=default entry and the cn=HTA.FHZ.CH entry
The correct entries should be as below:
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: default
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@HTA.FHZ.CH
dsMappedDN: uid=$1,ou=people,dc=hta,dc=fhz,dc=ch
dn: cn=HTA.FHZ.CH,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: HTA.FHZ.CH
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@HTA.FHZ.CH
dsMappedDN: uid=$1,ou=people,dc=hta,dc=fhz,dc=ch
Regards,
Ludovic.
# 6
hey ludovic.
thanks for your answer... first i was very happy because i was thinking that we really made just this little stupid mistake... but it didnt help :-(
i did the following:
-delete the old identity mapping.
made a new file gssapi-ludovic.ldif:
"gssapi_ludovic.ldif" 24 lines, 685 characters
dn: cn=GSSAPI,cn=identity mapping,cn=config
objectclass: nsContainer
objectclass: top
cn: GSSAPI
dn: cn=default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: default
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@HTA.FHZ.CH
dsMappedDN: uid=$1,ou=people,dc=hta,dc=fhz,dc=ch
dn: cn=HTA.FHZ.CH,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: HTA.FHZ.CH
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@HTA.FHZ.CH
dsMappedDN: uid=$1,ou=people,dc=hta,dc=fhz,dc=ch
added it to the ds:
# ldapmodify -h sso1.hta.fhz.ch -p 389 -D "cn=Directory Manager" -w password -f gssapi_ludovic.ldif -a
adding new entry cn=GSSAPI,cn=identity mapping,cn=config
adding new entry cn=default,cn=GSSAPI,cn=identity mapping,cn=config
adding new entry cn=HTA.FHZ.CH,cn=GSSAPI,cn=identity mapping,cn=config
-make a restart of the ds with directory server stop and start...
-get the ticket for the user vinci (the entry dn in the ds is uid:vinci,ou=people,dc=hta,dc=fhz,dc=ch)
-make the ldap request :
# kinit vinci
Password for vinci@HTA.FHZ.CH:
# ldapsearch -h sso1.hta.fhz.ch -p 389 -o mech=GSSAPI -b "" -s base "(objectclass=*)"
Please enter your authorization name:vinci
ldap_sasl_interactive_bind_s: Invalid credentials
ldap_sasl_interactive_bind_s: additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No error)
it also dont work when i take the authorizationname "vinci@HTA.FHZ.CH":
# ldapsearch -h sso1.hta.fhz.ch -p 389 -o mech=GSSAPI -b "" -s base "(objectclass=*)"
Please enter your authorization name:vinci@HTA.FHZ.CH
ldap_sasl_interactive_bind_s: Invalid credentials
ldap_sasl_interactive_bind_s: additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No error)
but i get the tickets from kerberso for user vinci and for the ldap service from sso1.hta.fhz.ch ( i do this request from test.hta.fhz.ch):
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: vinci@HTA.FHZ.CH
Valid startingExpiresService principal
06/07/06 21:49:24 06/08/06 05:49:24 krbtgt/HTA.FHZ.CH@HTA.FHZ.CH
renew until 06/14/06 21:49:24
06/07/06 21:49:47 06/08/06 05:49:24 ldap/sso1.hta.fhz.ch@HTA.FHZ.CH
renew until 06/14/06 21:49:24
perhaps this helps: at the acces file (var/mps/serverroot/slapd-sso1/logs/access) i have the following entries:
[07/Jun/2006:22:06:55 +0200] conn=34 op=-1 msgId=-1 - fd=40 slot=40 LDAP connection from 147.88.97.3 to 147.88.97.11
[07/Jun/2006:22:06:57 +0200] conn=34 op=0 msgId=1 - BIND dn="" method=sasl version=3 mech=GSSAPI
[07/Jun/2006:22:06:57 +0200] conn=34 op=0 msgId=1 - RESULT err=49 tag=97 nentries=0 etime=0
[07/Jun/2006:22:06:57 +0200] conn=34 op=1 msgId=2 - UNBIND
hope to get some more help soon. our project "should" be finished in about 3 weeks.... we tried now almoust everything ...
# 7
Hey,
Have you tried to use the ldapsearch tool provided with the Directory Server ?
The syntax is a little bit different (as I don't think it'll probe the authzid)...
ldapsearch -h sso1.hta.fhz.ch -o mech=GSSAPI -o authid="vinci@HTA.FHZ.CH" -o authzid="vinci@HTA.FHZ.CH" -b "" -s base "(objectclass=*)"
Ludovic.
# 8
hey ludovic...
i allready tried this one an i got the same failure:
# ldapsearch -h sso1.hta.fhz.ch -o mech=GSSAPI -o authid="vinci@HTA.FHZ.CH" -o authzid="vinci@HTA.FHZ.CH" -b "" -s base "(objectclass=*)"
ldap_sasl_interactive_bind_s: Invalid credentials
ldap_sasl_interactive_bind_s: additional info: SASL(-1): generic failure: GSSAPI Error: No credentials were supplied, or the credentials were unavailable or inaccessible (No error)
thanks anyway for your help...
# 9
I suggest that you enable the Access Logs for internal operations.
The identity mapping feature makes use of internal search operation.
By enabling the internal operations in the log, you will be able to see what is the search request issued and what is the result code. This may give you some indication of why it's not mapping properly from the authzid to an entry in the Directory.
To enable internal ops to be logged in Access, set the nsslapd-accesslog-level to 260 (256 + 4). To restore the default value, set it back to 256.
Ludovic.
# 10
hey ludovic.
thanks again for your help.
i set the nsslapd-accesslog-level:260 in the file /var/mps/serverroot/slapd-sso1/config/dse.ldif and started the ds.
in the access-log file: /var/mps/serverroot/slapd-sso1/logs/access
there are the following entries:
[09/Jun/2006:17:08:13 +0200] conn=6 op=-1 msgId=-1 - fd=29 slot=29 LDAP connection from 147.88.97.3 to 147.88.97.11
[09/Jun/2006:17:08:13 +0200] conn=6 op=0 msgId=1 - BIND dn="" method=sasl version=3 mech=GSSAPI
[09/Jun/2006:17:08:13 +0200] conn=-1 op=-1 msgId=-1 - SRCH base="" scope=0 filter="(|(objectclass=*)(objectclass=ldapsubentry))" attrs=ALL
[09/Jun/2006:17:08:13 +0200] conn=-1 op=-1 msgId=-1 - SRCH base="cn=config" scope=2 filter="objectclass=vlvsearch" attrs=ALL
[09/Jun/2006:17:08:13 +0200] conn=-1 op=-1 msgId=-1 - RESULT err=0 tag=48 nentries=21 etime=0
[09/Jun/2006:17:08:13 +0200] conn=-1 op=-1 msgId=-1 - RESULT err=0 tag=48 nentries=1 etime=0
[09/Jun/2006:17:08:13 +0200] conn=6 op=0 msgId=1 - RESULT err=49 tag=97 nentries=0 etime=0
[09/Jun/2006:17:08:13 +0200] conn=6 op=1 msgId=2 - UNBIND
[09/Jun/2006:17:08:13 +0200] conn=6 op=1 msgId=-1 - closing - U1
[09/Jun/2006:17:08:14 +0200] conn=6 op=-1 msgId=-1 - closed.
i allready searched for the failure code 49 but i just found a little description but nothing new !
see you
# 11
Hi, I am wondering if you ever solved this problem? I am having the same problem - error 49!Thanksjv11@cornell.edu
# 12
I'm also intrested if there is a soloution to this.....--Stebo
# 13
Hi masta,
I hope you have resolve the issue by now.
But, if not, this is some thoughts.
1. Check is some custom plug-in, cause the problem. I have some plug-ins that cause it. So I create a new instance, without custom plug-in
2. Try to put only this, nothing else (just for the sake for simplicity) :
dn: default,cn=GSSAPI,cn=identity mapping,cn=config
objectclass: dsIdentityMapping
objectclass: dsPatternMatching
objectclass: nsContainer
objectclass: top
cn: default
dsMatching-pattern: ${Principal}
dsMatching-regexp: (.*)@(.*)
dsMappedDN: uid=$1,people,dc=mydomain,dc=com
3. if the KDC and Sun DS different machine, create a new keytab (krb5.keytab) which contains only the "ldap/sso1.hta.fhz.ch". You can delete the other key. Place it in /etc/krb5/krb5.keytab. Make sure, you "ldap user" can read this. Cuz, your ldap server need to decrypt the service key. If ldap server cannot do this, you might get :
... SASL(-1): generic failure: .....
Here is what i got :
ldapsearch -h "machine1.mydomain.com" -p "14788" -o mech=GSSAPI -o authid=krbuser3@MYDOMAIN.COM -o authzid=krbuser3@MYDOMAIN.COM -b "dc=mydomain,dc=com" -s "sub" -v "objectclass=*"
access log :
[21/Nov/2006:12:53:16 -0500] conn=38 op=-1 msgId=-1 - fd=41 slot=41 LDAP connection from y.y.y.y to x.x.x.x
[21/Nov/2006:12:53:16 -0500] conn=38 op=0 msgId=1 - BIND dn="" method=sasl version=3 mech=GSSAPI
[21/Nov/2006:12:53:16 -0500] conn=38 op=0 msgId=1 - RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[21/Nov/2006:12:53:16 -0500] conn=38 op=1 msgId=2 - BIND dn="" method=sasl version=3 mech=GSSAPI
[21/Nov/2006:12:53:16 -0500] conn=38 op=1 msgId=2 - RESULT err=14 tag=97 nentries=0 etime=0, SASL bind in progress
[21/Nov/2006:12:53:16 -0500] conn=38 op=2 msgId=3 - BIND dn="" method=sasl version=3 mech=GSSAPI
[21/Nov/2006:12:53:16 -0500] conn=38 op=2 msgId=3 - RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=krbuser3,ou=people,dc=mydomain,dc=com"
[21/Nov/2006:12:53:16 -0500] conn=38 op=3 msgId=4 - SRCH base="dc=mydomain,dc=com" scope=2 filter="(objectClass=*)" attrs=ALL
[21/Nov/2006:12:53:16 -0500] conn=38 op=3 msgId=4 - RESULT err=0 tag=101 nentries=7 etime=0
[21/Nov/2006:12:53:17 -0500] conn=38 op=4 msgId=5 - UNBIND
[21/Nov/2006:12:53:17 -0500] conn=38 op=4 msgId=-1 - closing - U1
[21/Nov/2006:12:53:17 -0500] conn=38 op=-1 msgId=-1 - closed.
I also tried :
http://java.sun.com/products/jndi/tutorial/ldap/security/gssapi.html
But, it didn't give me the "err=14" .. In Progress. But, maybe that's another story (with JDK 1.4 or JDK 1.5).
cheers,
Martin
