FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Directory

 
 
LinkBack Thread Tools
 
Old 10-04-2010, 04:30 PM
Andrey Ivanov
 
Default GSSAPI authentication to Directory Server

Hi,

Try

kinit username
<mdp>
klist -e

/usr/bin/ldapsearch* -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"



klist -e
<you should see the additional ticket ldap/station1.example.com>
At least, that's how it works in our system


2010/10/4 Matt Carey <cvstealth2000@yahoo.com>


I'm trying to follow the Kerberos howto guide at http://directory.fedoraproject.org/wiki/Howto:Kerberos but am having an issue authenticating to the Directory Server with GSSAPI/Kerberos tickets:


$ /usr/lib/mozldap/ldapsearch -h station1.example.com -p 389 -o mech=GSSAPI -o authid="mcarey@STATION1.EXAMPLE.COM"* -o authzid="mcarey@STATION1.EXAMPLE.COM" -b "dc=example,dc=com" "(cn=*)"


Bind Error: Invalid credentials
Bind Error: additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

Attempt with OpenLDAP client:
$ /usr/bin/ldapsearch* -Y GSSAPI -X u:mcarey -b "" -s base -LLL -H ldap://station1.example.com -b "dc=example,dc=com"
"(cn=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
*** additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context




Resulting in the following entries in the access log on the DS:
# tail -5 access
[04/Oct/2010:10:44:14 -0400] conn=18 fd=68 slot=68 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:10:44:14 -0400] conn=18 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI


[04/Oct/2010:10:44:14 -0400] conn=18 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 UNBIND
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 fd=68 closed - U1


From what I can tell the Kerberos infrastructure and OS components are setup accordingly:


GSSAPI is a viable SASL mechanism:
$ /usr/lib/mozldap/ldapsearch -b "" -h station1 -p 389 -s base "(objectClass=*)" supportedSASLMechanisms
version:
1
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: ANONYMOUS


supportedSASLMechanisms: PLAIN

Directory Server keytab and contents:
# grep "nsslapd-localuser" dse.ldif
nsslapd-localuser: nobody
# ls -la ds.keytab
-rw------- 1 nobody nobody 172 Oct* 3 13:21 ds.keytab


# ktutil
ktutil:* rkt ./ds.keytab
ktutil:* l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
** 1*** 3 ldap/station1.example.com@STATION1.EXAMPLE.COM


** 2*** 3 ldap/station1.example.com@STATION1.EXAMPLE.COM
# grep KRB /etc/sysconfig/dirsrv
KRB5_KTNAME=/etc/dirsrv/ds.keytab ; export KRB5_KTNAME



SASL maps in Directory Server:
dn: cn=Kerberos uid
mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: (.*)@(.*).(.*)
nsSaslMapBaseDNTemplate: dc=2,dc=3
nsSaslMapFilterTemplate: (uid=1)



dn: cn=Station1 Kerberos Mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Station1 Kerberos Mapping
nsSaslMapRegexString: (.*)@STATATION1.EXAMPLE.COM


nsSaslMapFilterTemplate: (objectclass=inetOrgPerson)
nsSaslMapBaseDNTemplate: uid=1,ou=People,dc=example,dc=com

dn: cn=station1 map,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping


cn: example map
cn: station1 map
nsSaslMapRegexString: (.*)
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=1)

Getting a ticket from the KDC:
[mcarey@station1 ~]$ kdestroy


[mcarey@station1 ~]$ kinit
Password for
mcarey@STATION1.EXAMPLE.COM:
[mcarey@station1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@STATION1.EXAMPLE.COM


Valid starting**** Expires*********** Service principal
10/04/10 10:57:20* 10/04/10 17:37:20* krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM


Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached

Any help or pointers people have would be greatly appreciated.





--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 10-04-2010, 05:59 PM
Matt Carey
 
Default GSSAPI authentication to Directory Server

Andrey,

Thanks for the reply. I do see the ldap/station1.example.com ticket show up on the user end and I see the KDC issuing the ticket to the client, but I still get the SASL authentication failures. The one thing I see in the klist output is that the ldap ticket entry doesn't have the Kerberos REALM on it. Do you see that behavior as well in your implementation?

Client side:
[mcarey@station1 ~]$ kinit mcarey
Password for mcarey@STATION1.EXAMPLE.COM:
[mcarey@station1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@STATION1.EXAMPLE.COM

Valid starting**** Expires*********** Service principal
10/04/10 12:35:49* 10/04/10 19:15:49*
krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM
*** Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1


Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached
[mcarey@station1 ~]$ /usr/bin/ldap -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"
-bash: /usr/bin/ldap: No such file or directory
[mcarey@station1 ~]$ /usr/bin/ldapsearch -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
*** additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
[mcarey@station1 ~]$ klist -e
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@STATION1.EXAMPLE.COM

Valid starting****
Expires*********** Service principal
10/04/10 12:35:49* 10/04/10 19:15:49* krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM
*** Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
10/04/10 12:37:48* 10/04/10 19:15:49* ldap/station1.example.com@
*** Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1


Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached


KDC/DS side:
# tail -n0 -f /var/log/krb5kdc.log
Oct 04 12:39:06 station1.example.com krb5kdc[7514](info): AS_REQ (7 etypes {16 1 11 10 15 12 13}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@STATION1.EXAMPLE.COM for krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM
Oct 04 12:39:55 station1.example.com krb5kdc[7514](info): TGS_REQ
(2 etypes {16 1}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@STATION1.EXAMPLE.COM for ldap/station1.example.com@STATION1.EXAMPLE.COM
#

DS access log entries:
[04/Oct/2010:12:39:55 -0400] conn=8 fd=64 slot=64 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:12:39:55 -0400] conn=8 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI
[04/Oct/2010:12:39:55 -0400] conn=8 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:12:39:55 -0400] conn=8 op=-1 fd=64 closed - B1

--Matt

From: Andrey Ivanov <andrey.ivanov@polytechnique.fr>
To: General discussion list for the 389
Directory server project. <389-users@lists.fedoraproject.org>
Sent: Mon, October 4, 2010 12:30:43 PM
Subject: Re: [389-users] GSSAPI authentication to Directory Server


Hi,

Try

kinit username
<mdp>
klist -e

/usr/bin/ldapsearch* -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"



klist -e
<you should see the additional ticket ldap/station1.example.com>
At least, that's how it works in our system


2010/10/4 Matt Carey <cvstealth2000@yahoo.com>


I'm trying to follow the Kerberos howto guide at http://directory.fedoraproject.org/wiki/Howto:Kerberos but am having an issue authenticating to the Directory Server with GSSAPI/Kerberos tickets:


$ /usr/lib/mozldap/ldapsearch -h station1.example.com -p 389 -o mech=GSSAPI -o authid="mcarey@STATION1.EXAMPLE.COM"* -o authzid="mcarey@STATION1.EXAMPLE.COM" -b "dc=example,dc=com" "(cn=*)"


Bind Error: Invalid credentials
Bind Error: additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

Attempt with OpenLDAP client:
$ /usr/bin/ldapsearch* -Y GSSAPI -X u:mcarey -b "" -s base -LLL -H ldap://station1.example.com -b "dc=example,dc=com"
"(cn=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
*** additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context




Resulting in the following entries in the access log on the DS:
# tail -5 access
[04/Oct/2010:10:44:14 -0400] conn=18 fd=68 slot=68 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:10:44:14 -0400] conn=18 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI


[04/Oct/2010:10:44:14 -0400] conn=18 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 UNBIND
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 fd=68 closed - U1


From what I can tell the Kerberos infrastructure and OS components are setup accordingly:


GSSAPI is a viable SASL mechanism:
$ /usr/lib/mozldap/ldapsearch -b "" -h station1 -p 389 -s base "(objectClass=*)" supportedSASLMechanisms
version:
1
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: ANONYMOUS


supportedSASLMechanisms: PLAIN

Directory Server keytab and contents:
# grep "nsslapd-localuser" dse.ldif
nsslapd-localuser: nobody
# ls -la ds.keytab
-rw------- 1 nobody nobody 172 Oct* 3 13:21 ds.keytab


# ktutil
ktutil:* rkt ./ds.keytab
ktutil:* l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
** 1*** 3 ldap/station1.example.com@STATION1.EXAMPLE.COM


** 2*** 3 ldap/station1.example.com@STATION1.EXAMPLE.COM
# grep KRB /etc/sysconfig/dirsrv
KRB5_KTNAME=/etc/dirsrv/ds.keytab ; export KRB5_KTNAME



SASL maps in Directory Server:
dn: cn=Kerberos uid
mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: (.*)@(.*).(.*)
nsSaslMapBaseDNTemplate: dc=2,dc=3
nsSaslMapFilterTemplate: (uid=1)



dn: cn=Station1 Kerberos Mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Station1 Kerberos Mapping
nsSaslMapRegexString: (.*)@STATATION1.EXAMPLE.COM


nsSaslMapFilterTemplate: (objectclass=inetOrgPerson)
nsSaslMapBaseDNTemplate: uid=1,ou=People,dc=example,dc=com

dn: cn=station1 map,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping


cn: example map
cn: station1 map
nsSaslMapRegexString: (.*)
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=1)

Getting a ticket from the KDC:
[mcarey@station1 ~]$ kdestroy


[mcarey@station1 ~]$ kinit
Password for
mcarey@STATION1.EXAMPLE.COM:
[mcarey@station1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@STATION1.EXAMPLE.COM


Valid starting**** Expires*********** Service principal
10/04/10 10:57:20* 10/04/10 17:37:20* krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM


Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached

Any help or pointers people have would be greatly appreciated.





--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users












--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 
Old 10-05-2010, 10:10 AM
Andrey Ivanov
 
Default GSSAPI authentication to Directory Server

2010/10/4 Matt Carey <cvstealth2000@yahoo.com>


Andrey,

Thanks for the reply. I do see the ldap/station1.example.com ticket show up on the user end and I see the KDC issuing the ticket to the client, but I still get the SASL authentication failures. The one thing I see in the klist output is that the ldap ticket entry doesn't have the Kerberos REALM on it. Do you see that behavior as well in your implementation?



Client side:
[mcarey@station1 ~]$ kinit mcarey
Password for mcarey@STATION1.EXAMPLE.COM:
[mcarey@station1 ~]$ klist -e


Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@STATION1.EXAMPLE.COM

Valid starting**** Expires*********** Service principal


10/04/10 12:35:49* 10/04/10 19:15:49*
krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM
*** Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1




Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached
[mcarey@station1 ~]$ /usr/bin/ldap -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"


-bash: /usr/bin/ldap: No such file or directory
[mcarey@station1 ~]$ /usr/bin/ldapsearch -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"


SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
*** additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context
[mcarey@station1 ~]$ klist -e


Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@STATION1.EXAMPLE.COM

Valid starting****
Expires*********** Service principal
10/04/10 12:35:49* 10/04/10 19:15:49* krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM


*** Etype (skey, tkt): Triple DES cbc mode with HMAC/sha1, Triple DES cbc mode with HMAC/sha1
10/04/10 12:37:48* 10/04/10 19:15:49* ldap/station1.example.com@


It's strange you dont' have the REALM part of theldap/station1.example.com princinpal... So it won't be mapped by your "nsSaslMapRegexString: (.*)@STATATION1.EXAMPLE.COM". Verify that the server will be able to decrypt the data with its keytab :


kdestroy
kinit -k -t /etc/dirsrv/ds.keytab ' ldap/station1.example.com@STATION1.EXAMPLE.COM'


klist -e


I think you should also correct your mapping part. The default settings should be ok. And if you make your own mapping* you should follow the same syntax of the default entries, that is you should escape the parentheses (, it applies in particular to your "Station1 Kerberos Mapping" where nsSaslMapRegexString should be like (.*)@STATATION1.EXAMPLE.COM



If these verification are ok it means that either the server cannot correctly read the keytab or you don't have a user with uid=mcarey in your LDAP tree. To see more details in the access log you may switch on the logging of internal server searches : add 4 to the current value of nsslapd-accesslog-level attribute of cn=config, it should give something like


nsslapd-accesslog-level: 260

With internal searches logging enable you will see what exactly and how the server searches when it tries to map the principal to the entry

*@+




Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached


KDC/DS side:
# tail -n0 -f /var/log/krb5kdc.log


Oct 04 12:39:06 station1.example.com krb5kdc[7514](info): AS_REQ (7 etypes {16 1 11 10 15 12 13}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@STATION1.EXAMPLE.COM for krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM


Oct 04 12:39:55 station1.example.com krb5kdc[7514](info): TGS_REQ
(2 etypes {16 1}) 10.100.0.45: ISSUE: authtime 1286210346, etypes {rep=16 tkt=16 ses=16}, mcarey@STATION1.EXAMPLE.COM for ldap/station1.example.com@STATION1.EXAMPLE.COM


#

DS access log entries:
[04/Oct/2010:12:39:55 -0400] conn=8 fd=64 slot=64 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:12:39:55 -0400] conn=8 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI


[04/Oct/2010:12:39:55 -0400] conn=8 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:12:39:55 -0400] conn=8 op=-1 fd=64 closed - B1

--Matt



From: Andrey Ivanov <andrey.ivanov@polytechnique.fr>


To: General discussion list for the 389
Directory server project. <389-users@lists.fedoraproject.org>
Sent: Mon, October 4, 2010 12:30:43 PM


Subject: Re: [389-users] GSSAPI authentication to Directory Server


Hi,

Try

kinit username
<mdp>
klist -e

/usr/bin/ldapsearch* -Y GSSAPI -h station1.example.com -b "dc=example,dc=com" "(cn=*)"





klist -e
<you should see the additional ticket ldap/station1.example.com>
At least, that's how it works in our system




2010/10/4 Matt Carey <cvstealth2000@yahoo.com>


I'm trying to follow the Kerberos howto guide at http://directory.fedoraproject.org/wiki/Howto:Kerberos but am having an issue authenticating to the Directory Server with GSSAPI/Kerberos tickets:




$ /usr/lib/mozldap/ldapsearch -h station1.example.com -p 389 -o mech=GSSAPI -o authid="mcarey@STATION1.EXAMPLE.COM"* -o authzid="mcarey@STATION1.EXAMPLE.COM" -b "dc=example,dc=com" "(cn=*)"




Bind Error: Invalid credentials
Bind Error: additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context

Attempt with OpenLDAP client:
$ /usr/bin/ldapsearch* -Y GSSAPI -X u:mcarey -b "" -s base -LLL -H ldap://station1.example.com -b "dc=example,dc=com"
"(cn=*)"
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Invalid credentials (49)
*** additional info: SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context






Resulting in the following entries in the access log on the DS:
# tail -5 access
[04/Oct/2010:10:44:14 -0400] conn=18 fd=68 slot=68 connection from 10.100.0.45 to 10.100.0.45
[04/Oct/2010:10:44:14 -0400] conn=18 op=0 BIND dn="" method=sasl version=3 mech=GSSAPI




[04/Oct/2010:10:44:14 -0400] conn=18 op=0 RESULT err=49 tag=97 nentries=0 etime=0
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 UNBIND
[04/Oct/2010:10:44:14 -0400] conn=18 op=1 fd=68 closed - U1


From what I can tell the Kerberos infrastructure and OS components are setup accordingly:




GSSAPI is a viable SASL mechanism:
$ /usr/lib/mozldap/ldapsearch -b "" -h station1 -p 389 -s base "(objectClass=*)" supportedSASLMechanisms
version:
1
dn:
supportedSASLMechanisms: EXTERNAL
supportedSASLMechanisms: DIGEST-MD5
supportedSASLMechanisms: GSSAPI
supportedSASLMechanisms: LOGIN
supportedSASLMechanisms: CRAM-MD5
supportedSASLMechanisms: ANONYMOUS




supportedSASLMechanisms: PLAIN

Directory Server keytab and contents:
# grep "nsslapd-localuser" dse.ldif
nsslapd-localuser: nobody
# ls -la ds.keytab
-rw------- 1 nobody nobody 172 Oct* 3 13:21 ds.keytab




# ktutil
ktutil:* rkt ./ds.keytab
ktutil:* l
slot KVNO Principal
---- ---- ---------------------------------------------------------------------
** 1*** 3 ldap/station1.example.com@STATION1.EXAMPLE.COM




** 2*** 3 ldap/station1.example.com@STATION1.EXAMPLE.COM
# grep KRB /etc/sysconfig/dirsrv


KRB5_KTNAME=/etc/dirsrv/ds.keytab ; export KRB5_KTNAME



SASL maps in Directory Server:
dn: cn=Kerberos uid
mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Kerberos uid mapping
nsSaslMapRegexString: (.*)@(.*).(.*)
nsSaslMapBaseDNTemplate: dc=2,dc=3
nsSaslMapFilterTemplate: (uid=1)





dn: cn=Station1 Kerberos Mapping,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping
cn: Station1 Kerberos Mapping
nsSaslMapRegexString: (.*)@STATATION1.EXAMPLE.COM




nsSaslMapFilterTemplate: (objectclass=inetOrgPerson)
nsSaslMapBaseDNTemplate: uid=1,ou=People,dc=example,dc=com

dn: cn=station1 map,cn=mapping,cn=sasl,cn=config
objectClass: top
objectClass: nsSaslMapping




cn: example map
cn: station1 map
nsSaslMapRegexString: (.*)
nsSaslMapBaseDNTemplate: ou=People,dc=example,dc=com
nsSaslMapFilterTemplate: (cn=1)

Getting a ticket from the KDC:
[mcarey@station1 ~]$ kdestroy




[mcarey@station1 ~]$ kinit
Password for
mcarey@STATION1.EXAMPLE.COM:
[mcarey@station1 ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_5000_hYlO20
Default principal: mcarey@STATION1.EXAMPLE.COM




Valid starting**** Expires*********** Service principal
10/04/10 10:57:20* 10/04/10 17:37:20* krbtgt/STATION1.EXAMPLE.COM@STATION1.EXAMPLE.COM




Kerberos 4 ticket cache: /tmp/tkt5000
klist: You have no tickets cached

Any help or pointers people have would be greatly appreciated.





--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users













--

389 users mailing list

389-users@lists.fedoraproject.org

https://admin.fedoraproject.org/mailman/listinfo/389-users


--
389 users mailing list
389-users@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-users
 

Thread Tools




All times are GMT. The time now is 03:32 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org