[30905] in Kerberos
Re: SASL authentication
daemon@ATHENA.MIT.EDU (=?ISO-8859-1?Q?Michael_Str=F6der?=)
Sun Mar 22 17:23:29 2009
From: =?ISO-8859-1?Q?Michael_Str=F6der?= <michael@stroeder.com>
Date: Sat, 21 Mar 2009 00:54:48 +0100
Message-ID: <9vmd96-1dp.ln1@nb2.stroeder.com>
Mime-Version: 1.0
X-Complaints-To: usenet-abuse@t-online.de
In-Reply-To: <mailman.139.1237575932.14058.kerberos@mit.edu>
To: kerberos@mit.edu
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
Douglas E. Engert wrote:
> Xu, Qiang (FXSGSC) wrote:
>
> 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.
As I understood the original poster he wants to use LDAP SASL Bind with
mechanism GSSAPI in his LDAP client when accessing MS AD. For this to
work a normal kinit should be sufficient for a first test of his LDAP
client code.
If his own LDAP *client* runs as a long-running service (e.g. a
networked printer) then he would need a keytab extracted with the help
of ktpass.exe. AFAICS in these postings the first test did not succeed yet.
>> 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.
You create a user with a sAMAccountName and a userPrincipalName (LDAP
attribute names) and then use this userPrincipalName as parameter for
kinit. LDAP-bind with SASL/GSSAPI will automagically obtain a service
ticket. See my local test with OpenLDAP command-line tool below (all
names manually obfuscated).
If something fails check your DNS and /etc/krb5.conf especially
regarding enc types.
Maybe I got the original poster wrong though...
Ciao, Michael.
-----------Get Ticket Granting Ticket (TGT)-----------
$ kinit username@TESTDOMAIN.DOM
Password for username@TESTDOMAIN.DOM:
-----------List Tickets-----------
$ klist
Ticket cache: FILE:/tmp/krb5cc_4242
Default principal: username@TESTDOMAIN.DOM
Valid starting Expires Service principal
03/21/09 00:39:14 03/21/09 10:39:16 krbtgt/TESTDOMAIN.DOM@TESTDOMAIN.DOM
renew until 03/22/09 00:39:14
Kerberos 4 ticket cache: /tmp/tkt4242
klist: You have no tickets cached
-----------LDAP-Bind SASL/GSSAPI-----------
$ ldapsearch -H ldap://dc1.testdomain.dom -b "" -s base -Y GSSAPI
"(objectClass=*)" namingContexts
SASL/GSSAPI authentication started
SASL username: username@TESTDOMAIN.DOM
SASL SSF: 56
SASL data security layer installed.
dn:
namingContexts: DC=testdomain,DC=dom
namingContexts: CN=Configuration,DC=testdomain,DC=dom
namingContexts: CN=Schema,CN=Configuration,DC=testdomain,DC=dom
namingContexts: DC=DomainDnsZones,DC=testdomain,DC=dom
namingContexts: DC=ForestDnsZones,DC=testdomain,DC=dom
-----------List Tickets-----------
$ klist
Ticket cache: FILE:/tmp/krb5cc_4242
Default principal: username@TESTDOMAIN.DOM
Valid starting Expires Service principal
03/21/09 00:39:14 03/21/09 10:39:16 krbtgt/TESTDOMAIN.DOM@TESTDOMAIN.DOM
renew until 03/22/09 00:39:14
03/21/09 00:40:57 03/21/09 10:39:16 ldap/dc1.testdomain.dom@TESTDOMAIN.DOM
renew until 03/22/09 00:39:14
Kerberos 4 ticket cache: /tmp/tkt500
klist: You have no tickets cached
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
