Xu, Qiang (FXSGSC) wrote: >> -----Original Message----- >> From: Douglas E. Engert [mailto:[email protected]] >> Sent: Friday, March 20, 2009 9:09 AM >> To: Xu, Qiang (FXSGSC) >> Cc: Michael Ströder; [email protected] >> Subject: Re: SASL authentication >> >> Start with: >> http://technet.microsoft.com/en-us/library/bb742433.aspx >> Then look for ksetup program and 2003. >> Also look at Samba for net join and windbind and also look >> for msktutil. >> Solaris has a script to do this >
Michael said in an earilier note ktpass was not want you needed. Unless I missed something, I assumed the ldap service is going to be running on a Unix system. In which case ktpass is what you want. > In reference to http://technet.microsoft.com/en-us/library/bb742433.aspx, it > seems the only tool to use is ktpass. But the problem is, as I said before, I > don't know which user to associate in creating the keytab file. > The term "user account" used by Microsoft refers to the AD objectClass user. It has nothing to do with the user's who will be using the service. You are in effect creating a service account for the service, and ktpass will map the principal of the service to the account. Since account names can not have / and have to by 19 characters or less, you could name the account something like ldap-sesswin2003. > Anyway, I've given it a try. First, I created a user "ldapServer/Fair123" in > ADS of sesswin2003. Then: I don't think you can had the / in the name. The -mapuser parameter below has to match the account name. When you run ktpass it will update the AD account, *AND*and the keytab with the new pass and update the kvno. > ======================================================== > C:> ktpass -princ ldap/[email protected] -mapuser ldapServer > -pass Fair123 -out ldap.keytab > ======================================================== > It finished smoothly. Then I ftp'ed it to the printer, which is LDAP client > and Kerberos client. First I put it into "/etc/openldap", as suggested by > http://aput.net/~jheiss/krbldap/howto.html. ftp'ed what? To where? he ldap.keytab is for the ldap server, not the client. The default location of a keytab is /etc/krb5.keytab but can be somewhere else where the ldap server can access it. See KRB5_KTNAME env variable. > > But when I run "klist -k" in 98.190 to find the keytab file, it told me: > ======================================================== > q...@durian(pts/3):/etc/openldap[7]$ ll *.keytab > -rw-r--r-- 1 root root 69 Mar 20 15:01 ldap.keytab > > q...@durian(pts/3):/etc/openldap[8]$ klist -k > Keytab name: FILE:/etc/krb5.keytab Its looking for the default. See kinit parameters. > klist: No such file or directory while starting keytab scan > ======================================================== > It seemed to try to find a file named "krb5.keytab". > > OK, let's do it: > ======================================================== > q...@durian(pts/3):/etc/openldap[9]$ sudo mv /etc/openldap/ldap.keytab > /etc/krb5.keytab > Password: > > q...@durian(pts/3):/etc/openldap[10]$ cd /etc > > q...@durian(pts/3):/etc[11]$ ll krb* > -rw-r--r-- 1 root root 804 Mar 19 17:04 krb5.conf > -rw-r--r-- 1 root root 69 Mar 20 15:01 krb5.keytab > -rw-r--r-- 1 root root 143 Mar 19 16:34 krb.conf > > q...@durian(pts/3):/etc[12]$ klist -k > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 3 ldap/[email protected] > ======================================================== > It looks good. > > Then I tried to do Kerberos authentcation followed by ldapsearch: > ======================================================== > q...@durian(pts/3):/etc[14]$ kinit -f [email protected] > Password for [email protected]: > > q...@durian(pts/3):/etc[15]$ klist > Ticket cache: FILE:/tmp/krb5cc_20153 > Default principal: [email protected] > > Valid starting Expires Service principal > 03/20/09 15:07:19 03/21/09 01:06:54 krbtgt/[email protected] > renew until 03/21/09 15:07:19 > > > Kerberos 4 ticket cache: /tmp/tkt20153 > klist: You have no tickets cached > > q...@durian(pts/3):/etc[16]$ klist -k > Keytab name: FILE:/etc/krb5.keytab > KVNO Principal > ---- > -------------------------------------------------------------------------- > 3 ldap/[email protected] > > q...@durian(pts/3):/etc[17]$ ldapsearch -Y GSSAPI -H 'ldap://13.198.98.35' -b > 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=qxu' mail You need to use the FQDN of the server, not the IP number. GSSAPI/Kerberos use the FQDN to derive the principal name. > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified > GSS failure. Minor code may provide more information (Server not found in > Kerberos database) > ======================================================== > To my dismay, it still doesn't work. > > Any1 can shed some light on this? > > Thanks, > Xu Qiang > > -- Douglas E. Engert <[email protected]> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
