13 Replies Latest reply on Nov 21, 2006 6:05 PM by 807573

    GSSAPI Kerberos Directory Server 5.2

    807573
      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
      Password for vinci@HTA.FHZ.CH:
      bash-3.00$ klist
      Ticket cache: FILE:/tmp/krb5cc_111
      Default principal: vinci@HTA.FHZ.CH
      
      Valid starting                Expires                Service 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.CH for 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 starting                Expires                Service 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.2    mech_krb5.so kmech_krb5
      spnego                  1.3.6.1.5.5.2           mech_spnego.so.1 [msinterop]
      diffie_hellman_640_0    1.3.6.4.1.42.2.26.2.4   dh640-0.so.1
      diffie_hellman_1024_0   1.3.6.4.1.42.2.26.2.5   dh1024-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. Re: GSSAPI Kerberos Directory Server 5.2
          807573
          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. Re: GSSAPI Kerberos Directory Server 5.2
            807573
            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. Re: GSSAPI Kerberos Directory Server 5.2
              807573
              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. Re: GSSAPI Kerberos Directory Server 5.2
                807573
                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. Re: GSSAPI Kerberos Directory Server 5.2
                  807573
                  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. Re: GSSAPI Kerberos Directory Server 5.2
                    807573
                    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 starting                Expires                Service 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. Re: GSSAPI Kerberos Directory Server 5.2
                      807573
                      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. Re: GSSAPI Kerberos Directory Server 5.2
                        807573
                        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. Re: GSSAPI Kerberos Directory Server 5.2
                          807573
                          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. Re: GSSAPI Kerberos Directory Server 5.2
                            807573
                            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. Re: GSSAPI Kerberos Directory Server 5.2
                              807573
                              Hi, I am wondering if you ever solved this problem? I am having the same problem - error 49!

                              Thanks


                              jv11@cornell.edu
                              • 12. Re: GSSAPI Kerberos Directory Server 5.2
                                807573
                                I'm also intrested if there is a soloution to this.....

                                --Stebo                                                                                                                                                                                               
                                • 13. Re: GSSAPI Kerberos Directory Server 5.2
                                  807573
                                  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