[30904] in Kerberos
Re: SASL authentication
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Fri Mar 20 15:06:23 2009
X-Barracuda-Envelope-From: deengert@anl.gov
Message-ID: <49C3E8EE.8040805@anl.gov>
Date: Fri, 20 Mar 2009 14:05:18 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: "Xu, Qiang (FXSGSC)" <Qiang.Xu@fujixerox.com>
In-Reply-To: <D8C9BC7FFCF8154FB7141EB8DB609C1727084B37F3@SGPAPHQ-EXSCC01.dc01.fujixerox.net>
Cc: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>,
"kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="iso-8859-1"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Xu, Qiang (FXSGSC) wrote:
>> -----Original Message-----
>> From: Douglas E. Engert [mailto:deengert@anl.gov]
>> Sent: Friday, March 20, 2009 9:09 AM
>> To: Xu, Qiang (FXSGSC)
>> Cc: Michael Ströder; kerberos@mit.edu
>> 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/sesswin2003.com@SESSWIN2003.COM -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:
> ========================================================
> qxu@durian(pts/3):/etc/openldap[7]$ ll *.keytab
> -rw-r--r-- 1 root root 69 Mar 20 15:01 ldap.keytab
>
> qxu@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:
> ========================================================
> qxu@durian(pts/3):/etc/openldap[9]$ sudo mv /etc/openldap/ldap.keytab /etc/krb5.keytab
> Password:
>
> qxu@durian(pts/3):/etc/openldap[10]$ cd /etc
>
> qxu@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
>
> qxu@durian(pts/3):/etc[12]$ klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
> 3 ldap/sesswin2003.com@SESSWIN2003.COM
> ========================================================
> It looks good.
>
> Then I tried to do Kerberos authentcation followed by ldapsearch:
> ========================================================
> qxu@durian(pts/3):/etc[14]$ kinit -f qxu@SESSWIN2003.COM
> Password for qxu@SESSWIN2003.COM:
>
> qxu@durian(pts/3):/etc[15]$ klist
> Ticket cache: FILE:/tmp/krb5cc_20153
> Default principal: qxu@SESSWIN2003.COM
>
> Valid starting Expires Service principal
> 03/20/09 15:07:19 03/21/09 01:06:54 krbtgt/SESSWIN2003.COM@SESSWIN2003.COM
> renew until 03/21/09 15:07:19
>
>
> Kerberos 4 ticket cache: /tmp/tkt20153
> klist: You have no tickets cached
>
> qxu@durian(pts/3):/etc[16]$ klist -k
> Keytab name: FILE:/etc/krb5.keytab
> KVNO Principal
> ---- --------------------------------------------------------------------------
> 3 ldap/sesswin2003.com@SESSWIN2003.COM
>
> qxu@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 <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
