SASL authentication
Xu, Qiang (FXSGSC)
I am trying to do LDAP SASL binding to ADS in Windows 2003 server, which is where KDC resides at the same time.
Unfortunately, an error is confusing me:
==============================================
<apManager> (Fri Mar 13 2009 13:34:19.846) <p8124,t3078597536,aba_ldap_interface.c,2373>
INFO>> SASL Login
<apManager> (Fri Mar 13 2009 13:35:07.089) <p8124,t3078597536,aba_ldap_interface.c,2388>
INFO>> SASL LDAP BIND with GSSAPI: Value of ldapStatus 82
<apManager> (Fri Mar 13 2009 13:35:07.089) <p8124,t3078597536,aba_ldap_interface.c,2459>
ERROR>> LDAP BIND: Value of ldap failure status and text 82 Local error
==============================================
Using klist, it is verified that a Kerberos ticket exists and has not expired. Besides this, what else should be done at the server's end, or at the client's end? Any set-up issue? (the client has SASL library and its GSSAPI plugin in place, already)
Looking forward to help,
Xu Qiang
Michael Ströder
Try with obtaining the TGT with 'kinit -A <principal>'. I vaguely
remember that this solved some problems for me.
Ciao, Michael.
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
> Sent: Monday, March 16, 2009 7:18 PM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
> Try with obtaining the TGT with 'kinit -A <principal>'. I
> vaguely remember that this solved some problems for me.
What should the <principle> be? In my case, suppose the user to be authentcated is "qxu", with password "abcdefg".
Btw, from searching the web, it seems "82 Local error" may arises from the lacking of a keytab file. But should the keytab file in the server, or in the client? How to create a keytab file in Windows server 2003?
Thanks,
Xu Qiang
Michael Ströder
>> -----Original Message-----
>> From: kerberos...@mit.edu
>> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
>> Sent: Monday, March 16, 2009 7:18 PM
>> To: kerb...@mit.edu
>> Subject: Re: SASL authentication
>>
>> Try with obtaining the TGT with 'kinit -A <principal>'. I
>> vaguely remember that this solved some problems for me.
>
> What should the <principle> be? In my case, suppose the user to be authentcated is "qxu", with password "abcdefg".
Something like <username>@<REALM>. E.g. "q...@MIT.EDU" (without the quotes).
> Btw, from searching the web, it seems "82 Local error" may arises
> from the lacking of a keytab file. But should the keytab file in the
> server, or in the client? How to create a keytab file in Windows
> server 2003?
First try to do a kinit with providing the password. After that you
could try using keytab files (on your LDAP client) if needed in your setup.
Ciao, Michael.
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
> Sent: Tuesday, March 17, 2009 8:20 PM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
> that you could try using keytab files (on your LDAP client)
> if needed in your setup.
The tutorial at http://aput.net/~jheiss/krbldap/howto.html said my SASL ldap bindingerror of "82 Local error" may be due to the lack of a service principle:
=========================================================
ldap_sasl_interactive_bind_s: Local error
ldap/hostname service principal not set up
or your Kerberos ticket is expired
=========================================================
I am a little bit confused about it. Does it mean either the ticket is absent or the ticket has expired? Is "ldap/hostname service principal" and "kerberos ticket" here the same thing?
After kinit returns successfully, I can see there is a ticket in krb cache:
=========================================================
MBC113:/ <515> /tmp/dlms/kerberos/apps/klist -k
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: q...@SESSWIN2003.COM
Valid starting Expires Service principal
03/17/09 17:36:50 03/18/09 03:37:35 krbtgt/SESSWIN...@SESSWIN2003.COM
renew until 03/18/09 17:36:50
=========================================================
Isn't this ticket the service principal needed? You can see the third column's caption is "Service principal". Is it the same as or different from the "ldap/hostname service principal" mentioned in the above?
Suppose they are different, and as you told me, the keytab file (which contains the service principal of ldap/hostname) is used by LDAP client. But where should the keytab file be generated? Should the keytab file be created in Kerberos server or LDAP server? Could you teach me how to create this keytab file, as detailed as possible?
Thanks,
Xu Qiang
Michael Ströder
>> -----Original Message-----
>> From: kerberos...@mit.edu
>> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
>> Sent: Tuesday, March 17, 2009 8:20 PM
>> To: kerb...@mit.edu
>> Subject: Re: SASL authentication
>>
>> First try to do a kinit with providing the password. After
>> that you could try using keytab files (on your LDAP client)
>> if needed in your setup.
>
> The tutorial at http://aput.net/~jheiss/krbldap/howto.html said my
> SASL ldap bindingerror of "82 Local error" may be due to the lack of
> a service principle:
Did you try command-line option -A when invoking kinit as I suggested in
my previous posting? It seems you probably should read a bit more about
how Kerberos works especially regarding ticket types. There are tons of
docs out there.
Ciao, Michael.
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
> Sent: Tuesday, March 17, 2009 8:20 PM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
> that you could try using keytab files (on your LDAP client)
> if needed in your setup.
Found an example on how to create the keytab file at http://docs.hp.com/en/J4269-90049/ch04s03.html:
=============================================
Use the ktpass tool to create the keytab file and set up an identity mapping the host account.
The following is an example showing you how to run ktpass to create the keytab file for the HP-UX host myhost with the KDC realm cup.hp.com:
C:> ktpass -princ host/myh...@CUP.HP.COM -mapuser myhost -pass mypasswd -out unix.keytab
=============================================
>From the context, this seems to be done in the author's LDAP server, which is an ADS in Windows 2003 server.
For my case, Kerberos server and LDAP server are all in one machine with Windows 2003 server OS installed on it. Should it be the following format?
=============================================
C:> ktpass -princ ldap/sesswin...@SESSWIN2003.COM -mapuser sesswin2003.com -pass mypasswd -out ldap.keytab
=============================================
sesswin2003.com is a primary domain controller, and the only machine in its domain is itself. So the domain name is the same as the hostname. But in the ADS, shall I create a user named after the computer's hostname - "sesswin2003.com"? This seems ridiculous.
By the way, after the keytab file is generated, I would transfer it to the printer, which is the LDAP client. Which directory should I put the file in?
Or if I have missed anything? Looking forward to your help, Michael.
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
> Sent: Wednesday, March 18, 2009 2:34 PM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
> suggested in my previous posting? It seems you probably
> should read a bit more about how Kerberos works especially
> regarding ticket types. There are tons of docs out there.
Yes, I have tried the option -A. Originally I was using "kinit -f ...". Now I am using "kinit -f -A ...". As far as I know, the option -A is "do not include addresses". I can't see any gain here. After using -A option, the error msg is still "82 Local error" when doing SASL binding.
>From Google, I can only get a small number of materials on how to create a service principal under Windows 2003 Server. But they are all somewhat ambiguous, and I still can't figure out how to create a keytab file for LDAP client's use.
Thanks,
Xu Qiang
Douglas E. Engert
Xu, Qiang (FXSGSC) wrote:
>> -----Original Message-----
>> From: kerberos...@mit.edu
>> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
>> Sent: Wednesday, March 18, 2009 2:34 PM
>> To: kerb...@mit.edu
>> Subject: Re: SASL authentication
>>
>> Did you try command-line option -A when invoking kinit as I
>> suggested in my previous posting? It seems you probably
>> should read a bit more about how Kerberos works especially
>> regarding ticket types. There are tons of docs out there.
>
> Yes, I have tried the option -A. Originally I was using "kinit -f ...". Now I am using "kinit -f -A ...". As far as I know, the option -A is "do not include addresses". I can't see any gain here. After using -A option, the error msg is still "82 Local error" when doing SASL binding.
>
>>From Google, I can only get a small number of materials on how to create a service principal under Windows 2003 Server. But they are all somewhat ambiguous, and I still can't figure out how to create a keytab file for LDAP client's use.
>
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
> Thanks,
> Xu Qiang
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEn...@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
Xu, Qiang (FXSGSC)
> From: Douglas E. Engert [mailto:deen...@anl.gov]
> Sent: Friday, March 20, 2009 9:09 AM
> To: Xu, Qiang (FXSGSC)
> Cc: Michael Ströder; kerb...@mit.edu
> Subject: Re: SASL authentication
>
> 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
Hi, Douglas:
Thanks for providing the URL for my reference. It is helpful, but I still have some questions.
Here is the tutorial said:
=============================================
To create a service instance account in Active Directory
1. Use the Active Directory Management tool to create a user account for the UNIX service; for example, create an account with the name sampleUnix1.
2. Use the Ktpass tool to set up an identity mapping for the user account. Use this command:
C:> Ktpass princ service-instance@REALM mapuser account-name -pass password -out unixmachine.keytab
The format of the Kerberos service-instance name is: service/host.realm_name, for example:
C:> ktpass princ sample/unix1.re...@RESKIT.COM -mapuser sampleUnix1 pass password out unix1.keytab
In this case, an account is created with a meaningful name sampleUnix1, and a service principal name mapping is added for sample/unix1.reskit.com. This is the purpose of using Ktpass with the princ and mapuser switches.
3. Merge the keytab file with the /etc/krb5.keytab file on the UNIX host.
=============================================
Apart from this, things like ksetup seems irrelavant to my case.
For my case, I want to add an LDAP service principle into the keytab file, so it probably should be:
=============================================
C:> ktpass princ ldap/sesswin...@SESSWIN2003.COM -mapuser <what_should_i_put_here> pass <what_should_i_put_here> out ldap.keytab
=============================================
In our environment, there is a domain called "SESSWIN2003.COM", and there is only one machine in this domain, with the hostname called "sesswin2003.com". But to create the keytab file for the LDAP server (ADS in the same machine), what user/password should I set?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From: Nikhil Mishra [mailto:nik...@gs-lab.com]
> Sent: Friday, March 20, 2009 12:57 PM
> To: Xu, Qiang (FXSGSC)
> 1. What is your host server ? ( like windows server 2003 SP2
> SE , EE ) 2. What is your ktpass version ?
>
> I have done quite an extensive exercise on this recently and
> so please take care of following things :
>
> 1.Its very important you have the right version of ktpass on
> right operating system .
How to check the version of ktpass? I typed "ktpass /?", but didn't find any option or switch to show its version number. My Kerberos server is the same as LDAP server, both integrated into ADS in the same machine (sesswin2003.com) with OS as Windows Server 2003 Enterprise Edition 5.2.3790, with Service Pack 1, Build 3790.
> 2. Please use right options with ktpass .
Could you give me some suggestions on the correct usage of ktpass command? Did I miss anything in the following command?
=====================================
C:> ktpass princ ldap/sesswin...@SESSWIN2003.COM -mapuser <what_should_i_put_here> pass <what_should_i_put_here> out ldap.keytab"?
=====================================
I am looking forward to your help.
Thanks a lot,
Xu Qiang
Xu, Qiang (FXSGSC)
> From: Nikhil Mishra [mailto:nik...@gs-lab.com]
> Sent: Friday, March 20, 2009 1:43 PM
> To: Xu, Qiang (FXSGSC)
> Subject: Re: SASL authentication
>
>
> Goto c:/Program Files/Support tools/ or wherever your
> ktpass.exe is present.
>
>
> right click on ktpass->Properties->Version->File Version.
>
> "Right click does wonders on windows I didn,t even knew :-) "
As you instructed, the version of ktpass is verified to be "5.2.3790.0".
> Please download support tools for windows server 2003 SP2.
> This one worked in most cases .
I suspect SP1 is enough for my case. But I don't know what user should I associate with the LDAP server hostname in creating the keytab file.
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> To: Xu, Qiang (FXSGSC)
> 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
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.
Anyway, I've given it a try. First, I created a user "ldapServer/Fair123" in ADS of sesswin2003. Then:
========================================================
C:> ktpass -princ ldap/sesswin...@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.
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
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/sesswin...@SESSWIN2003.COM
========================================================
It looks good.
Then I tried to do Kerberos authentcation followed by ldapsearch:
========================================================
qxu@durian(pts/3):/etc[14]$ kinit -f q...@SESSWIN2003.COM
Password for q...@SESSWIN2003.COM:
qxu@durian(pts/3):/etc[15]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: q...@SESSWIN2003.COM
Valid starting Expires Service principal
03/20/09 15:07:19 03/21/09 01:06:54 krbtgt/SESSWIN...@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/sesswin...@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
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
Nikhil Mishra
Goto c:/Program Files/Support tools/ or
wherever your ktpass.exe is present.
right click on ktpass->Properties->Version->File Version.
"Right click does wonders on windows I didn,t even knew :-) "
Please download support tools for windows server 2003 SP2.
This one worked in most cases .
--Nikhil
Xu, Qiang (FXSGSC) wrote:
>> -----Original Message-----
>> From: Nikhil Mishra [mailto:nik...@gs-lab.com]
>> Sent: Friday, March 20, 2009 12:57 PM
>> To: Xu, Qiang (FXSGSC)
>> Cc: Douglas E. Engert; Michael Ströder; kerb...@mit.edu
>> Subject: Re: SASL authentication
>>
>> Few questions before we go ahead :
>> 1. What is your host server ? ( like windows server 2003 SP2
>> SE , EE ) 2. What is your ktpass version ?
>>
>> I have done quite an extensive exercise on this recently and
>> so please take care of following things :
>>
>> 1.Its very important you have the right version of ktpass on
>> right operating system .
>>
>
> How to check the version of ktpass? I typed "ktpass /?", but didn't find any option or switch to show its version number. My Kerberos server is the same as LDAP server, both integrated into ADS in the same machine (sesswin2003.com) with OS as Windows Server 2003 Enterprise Edition 5.2.3790, with Service Pack 1, Build 3790.
>
>
>> 2. Please use right options with ktpass .
>>
>
> Could you give me some suggestions on the correct usage of ktpass command? Did I miss anything in the following command?
> =====================================
> C:> ktpass princ ldap/sesswin...@SESSWIN2003.COM -mapuser <what_should_i_put_here> pass <what_should_i_put_here> out ldap.keytab"?
> =====================================
> I am looking forward to your help.
>
> Thanks a lot,
> Xu Qiang
Nikhil Mishra
Please find my comments inline.
Xu, Qiang (FXSGSC) wrote:
>> -----Original Message-----
>> From: Douglas E. Engert [mailto:deen...@anl.gov]
>> Sent: Friday, March 20, 2009 9:09 AM
>> To: Xu, Qiang (FXSGSC)
>> Cc: Michael Ströder; kerb...@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
>>
>
> Hi, Douglas:
>
> Thanks for providing the URL for my reference. It is helpful, but I still have some questions.
>
> Here is the tutorial said:
> =============================================
> To create a service instance account in Active Directory
>
> 1. Use the Active Directory Management tool to create a user account for the UNIX service; for example, create an account with the name sampleUnix1.
>
That is correct.
> 2. Use the Ktpass tool to set up an identity mapping for the user account. Use this command:
>
> C:> Ktpass princ service-instance@REALM mapuser account-name -pass password -out unixmachine.keytab
>
> The format of the Kerberos service-instance name is: service/host.realm_name, for example:
>
> C:> ktpass princ sample/unix1.re...@RESKIT.COM -mapuser sampleUnix1 pass password out unix1.keytab
>
> In this case, an account is created with a meaningful name sampleUnix1, and a service principal name mapping is added for sample/unix1.reskit.com. This is the purpose of using Ktpass with the princ and mapuser switches.
>
>
Try -setupn -setpass /ptype KRB5_NTPRINCIPAL options as well .
> 3. Merge the keytab file with the /etc/krb5.keytab file on the UNIX host.
> =============================================
> Apart from this, things like ksetup seems irrelavant to my case.
>
>
Ksetup is useless in your case.It is used for a windows machine to join
a Linux KDC.
> For my case, I want to add an LDAP service principle into the keytab file, so it probably should be:
> =============================================
> C:> ktpass princ ldap/sesswin...@SESSWIN2003.COM -mapuser <what_should_i_put_here> pass <what_should_i_put_here> out ldap.keytab
> =============================================
> In our environment, there is a domain called "SESSWIN2003.COM", and there is only one machine in this domain, with the hostname called "sesswin2003.com". But to create the keytab file for the LDAP server (ADS in the same machine), what user/password should I set?
>
>
Few questions before we go ahead :
1. What is your host server ? ( like windows server 2003 SP2 SE , EE )
2. What is your ktpass version ?
I have done quite an extensive exercise on this recently and so please take
care of following things :
1.Its very important you have the right version of ktpass on right
operating system .
2. Please use right options with ktpass .
> Thanks,
> Xu Qiang
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
Thanks
nikhil
Douglas E. Engert
Xu, Qiang (FXSGSC) wrote:
>> -----Original Message-----
>> From: Douglas E. Engert [mailto:deen...@anl.gov]
>> Sent: Friday, March 20, 2009 9:09 AM
>> To: Xu, Qiang (FXSGSC)
>> Cc: Michael Ströder; kerb...@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/sesswin...@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.
> Default principal: q...@SESSWIN2003.COM
>
> Valid starting Expires Service principal
> 03/20/09 15:07:19 03/21/09 01:06:54 krbtgt/SESSWIN...@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/sesswin...@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
>
>
--
Michael Ströder
> 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 user...@TESTDOMAIN.DOM
Password for user...@TESTDOMAIN.DOM:
-----------List Tickets-----------
$ klist
Ticket cache: FILE:/tmp/krb5cc_4242
Default principal: user...@TESTDOMAIN.DOM
Valid starting Expires Service principal
03/21/09 00:39:14 03/21/09 10:39:16 krbtgt/TESTDOM...@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: user...@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: user...@TESTDOMAIN.DOM
Valid starting Expires Service principal
03/21/09 00:39:14 03/21/09 10:39:16 krbtgt/TESTDOM...@TESTDOMAIN.DOM
renew until 03/22/09 00:39:14
03/21/09 00:40:57 03/21/09 10:39:16 ldap/dc1.testd...@TESTDOMAIN.DOM
renew until 03/22/09 00:39:14
Kerberos 4 ticket cache: /tmp/tkt500
Xu, Qiang (FXSGSC)
> From: Douglas E. Engert [mailto:deen...@anl.gov]
> Sent: Saturday, March 21, 2009 3:05 AM
> To: Xu, Qiang (FXSGSC)
> 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.
Both LDAP service and Kerberos service are running in the same machine, equipped with Windows 2003 Server OS. So only ktpass is available to generate a keytab file. The LDAP client in the printer is running on a Wind River Linux system.
> 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.
In my example, the username is "ldapServer", "Fair123" is the password associated with this user. Sorry for the confusion.
> > ========================================================
> > C:> ktpass -princ ldap/sesswin...@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?
> the 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.
I ftp'ed the output of ktpass command, the keytab file "ldap.keybab" into the printer, which is an LDAP client. The client will use it to identify the LDAP server in SASL communication with the Kerberos server. Michael also pointed it out previously. The following is what Michael said before:
============================
First try to do a kinit with providing the password. After that you could try using keytab files (on your LDAP client) if needed in your setup.
============================
You mean the keytab file should be put in the LDAP server? My LDAP server is ADS in Windows 2003 Server EE, so where should I put it?
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
> 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.
Yes, my LDAP client runs in a networked printer, which is not in the same realm as the Kerberos server and LDAP server. Therefore, maybe a keytab file is necessary for me?
> 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.
Basically, my test is almost the same as what you've done in the following. But in doing ldapsearch, I've met an error:
========================================================
qxu@durian(pts/3):/etc[14]$ kinit -f q...@SESSWIN2003.COM
Password for q...@SESSWIN2003.COM:
qxu@durian(pts/3):/etc[15]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: q...@SESSWIN2003.COM
Valid starting Expires Service principal
03/20/09 15:07:19 03/21/09 01:06:54 krbtgt/SESSWIN...@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[17]$ ldapsearch -Y GSSAPI -H 'ldap://13.198.98.35' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=qxu' mail
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)
========================================================
Is the message "Server not found in Kerberos database" means I need a keytab file?
Thank you, Michael!
Xu Qiang
Xu, Qiang (FXSGSC)
> From: Douglas E. Engert [mailto:deen...@anl.gov]
> Sent: Saturday, March 21, 2009 3:05 AM
> To: Xu, Qiang (FXSGSC)
> GSSAPI/Kerberos use the FQDN to derive the principal name.
As you suggested, I use the following expressions:
==========================================
qxu@durian(pts/3):/etc[19]$ ldapsearch -Y GSSAPI -H 'ldap://sesswin2003.sesswin2003.com' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=qxu' mail
ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1)
==========================================
The domain name is "sesswin2003.com", the host name is "sesswin2003". Thus the FQDN in the expression is "sesswin2003.sesswin2003.com". But the result seems worse.
Did I miss anything?
Thank you, Doug!
Xu Qiang
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
> 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.
Yes, now I am also suspecting something is wrong with DNS settings. But I don't know how to check them. Could you give me some examples?
The following is the content of my /etc/krb5.conf:
=======================================
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
default_realm = durian.fujixerox.com
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
SESSWIN2003.COM = {
kdc = 13.198.98.35:88
default_domain = sesswin2003.com
}
durian.fujixerox.com = {
kdc = kerberos.durian.fujixerox.com:88
admin_server = kerberos.durian.fujixerox.com:749
}
[domain_realm]
.sesswin2003.com = SESSWIN2003.COM
sesswin2003.com = SESSWIN2003.COM
durian.fujixerox.com = durian.fujixerox.com
.durian.fujixerox.com = durian.fujixerox.com
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
=======================================
In this configuration file, "durian" is the hostname of the client machine. Is there anything wrong with it?
Thanks,
Xu Qiang
Michael Ströder
>
> Yes, now I am also suspecting something is wrong with DNS settings.
> But I don't know how to check them. Could you give me some examples?
Use nslookup.exe on host name and IP address. They must match.
> [libdefaults]
> default_realm = durian.fujixerox.com
> [..]
> In this configuration file, "durian" is the hostname of the client
> machine. Is there anything wrong with it?
I'm confused. Why do you put in durian.fujixerox.com here.
default_realm MUST point to a Kerberos realm. In a MS AD environment
this is simply the upper-case DNS domain name of the AD domain.
> [realms]
> SESSWIN2003.COM = {
> kdc = 13.198.98.35:88
^^^^^^^^^^^^
Is that the IP address of your AD domain controller? Is SESSWIN2003.COM
your AD domain?
> durian.fujixerox.com = {
> kdc = kerberos.durian.fujixerox.com:88
> admin_server = kerberos.durian.fujixerox.com:749
> }
Likely you should remove that.
You should try to find a working setup with AD using your favourite
search engine. Please read a little bit more what the different
parameters really mean.
Ciao, Michael.
Markus Moeller
traffic from your client when you do the following
On the client:
kinit q...@SESSWIN2003.COM
ldapsearch -Y GSSAPI -H 'ldap://sesswin2003.sesswin2003.com' -b
'dc=sesswin2003,dc=com' -s sub -LLL '(cn=qxu)' mail
Make sure that sesswin2003.sesswin2003.com resolves to the correct ip or is
in your hosts file.
Markus
"Xu, Qiang (FXSGSC)" <Qian...@fujixerox.com> wrote in message
news:mailman.142.123778...@mit.edu...
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Markus Moeller
> Sent: Tuesday, March 24, 2009 7:26 AM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
> server of all traffic from your client when you do the following
>
> On the client:
> kinit q...@SESSWIN2003.COM
> ldapsearch -Y GSSAPI -H 'ldap://sesswin2003.sesswin2003.com'
> -b 'dc=sesswin2003,dc=com' -s sub -LLL '(cn=qxu)' mail
>
> Make sure that sesswin2003.sesswin2003.com resolves to the
> correct ip or is in your hosts file.
Just as you guess, Markus, there is no network traffic arriving at the LDAP server when I run ldapsearch command. In contrast, when I run kinit command, ethereal can help me capture Kerberos packets. So it seems the FQDN "sesswin2003.sesswin2003.com" cannot be resolved.
Shall I do something to the file "/etc/hosts"? Could you give me some suggestion on how to resolve this name? Please note that the client (where kinit and ldapsearch are run) is not in the domain "sesswin2003.com".
Thanks,
Xu Qiang
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
> Sent: Tuesday, March 24, 2009 3:22 AM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
Thanks, Michael! Using nslookup in the client Linux box, I found it is the reason why there is no outward LDAP traffic. The LDAP server (AD in Windows 2003 Server), as I said, is the primary domain controller of its own. It is also the DNS server in its own domain. I didn't recognize that this DNS server is not in the nameserver list of the client machine. No wonder it can not resolve the name. Now it is added into the file "/etc/resolv.conf":
==========================================================
search sgp.fujixerox.com sesswin2003.com /* sesswin2003.com is the domain name of the AD server */
nameserver 13.198.8.83
nameserver 13.198.96.10
nameserver 13.198.98.35 /* This is the IP Address of the domain controller with its FQDN as sesswin2003.sesswin2003.com */
==========================================================
But strangely, with this file modified, "nslookup sesswin2003" still fails. To my surprise, even in the AD itself, this command fails. So I suspect DNS in the AD is not running properly. Could you tell me where to look at in the AD to fix the DNS issue?
> > [libdefaults]
> > default_realm = durian.fujixerox.com
> > [..]
> > In this configuration file, "durian" is the hostname of the client
> > machine. Is there anything wrong with it?
>
> I'm confused. Why do you put in durian.fujixerox.com here.
>
> default_realm MUST point to a Kerberos realm. In a MS AD
> environment this is simply the upper-case DNS domain name of
> the AD domain.
durian is the hostname of the client Linux box. fujixerox.com is the domain name in which the client lies.
Yes, I also feel this is strange setting. durian.fujixerox.com is FQDN of the client, not a domain name.
But since it has nothing to do with the LDAP traffic, I don't want to change it now.
> > [realms]
> > SESSWIN2003.COM = {
> > kdc = 13.198.98.35:88
> ^^^^^^^^^^^^
> Is that the IP address of your AD domain controller? Is
> SESSWIN2003.COM your AD domain?
Yes, this is the IP address of the AD domain controller. And Yes again, SESSWIN2003.COM is my AD domain.
> > durian.fujixerox.com = {
> > kdc = kerberos.durian.fujixerox.com:88
> > admin_server = kerberos.durian.fujixerox.com:749 }
>
> Likely you should remove that.
>
> You should try to find a working setup with AD using your
> favourite search engine. Please read a little bit more what
> the different parameters really mean.
Thanks a lot,
Xu Qiang
Markus Moeller
>> -----Original Message-----
>> From: kerberos...@mit.edu
>> [mailto:kerberos...@mit.edu] On Behalf Of Michael Str?der
>> Sent: Tuesday, March 24, 2009 3:22 AM
>> To: kerb...@mit.edu
>> Subject: Re: SASL authentication
>>
>
> reason why there is no outward LDAP traffic. The LDAP server (AD in
> Windows 2003 Server), as I said, is the primary domain controller of its
> own. It is also the DNS server in its own domain. I didn't recognize that
> this DNS server is not in the nameserver list of the client machine. No
> wonder it can not resolve the name. Now it is added into the file
> "/etc/resolv.conf":
> ==========================================================
> search sgp.fujixerox.com sesswin2003.com /* sesswin2003.com is the domain
> name of the AD server */
> nameserver 13.198.8.83
> nameserver 13.198.96.10
> nameserver 13.198.98.35 /* This is the IP Address of the domain controller
> with its FQDN as sesswin2003.sesswin2003.com */
> ==========================================================
> But strangely, with this file modified, "nslookup sesswin2003" still
> fails. To my surprise, even in the AD itself, this command fails. So I
> suspect DNS in the AD is not running properly. Could you tell me where to
> look at in the AD to fix the DNS issue?
You need to do nslookup sesswin2003.sesswin2003.com or nslookup
sesswin2003.com or add a search path to your resolv.conf file (e.g. search
sesswin2003.com)
>
>> > [libdefaults]
>> > default_realm = durian.fujixerox.com
>> > [..]
>> > In this configuration file, "durian" is the hostname of the client
>> > machine. Is there anything wrong with it?
>>
>> I'm confused. Why do you put in durian.fujixerox.com here.
>>
>> default_realm MUST point to a Kerberos realm. In a MS AD
>> environment this is simply the upper-case DNS domain name of
>> the AD domain.
>
> durian is the hostname of the client Linux box. fujixerox.com is the
> domain name in which the client lies.
> Yes, I also feel this is strange setting. durian.fujixerox.com is FQDN of
> the client, not a domain name.
>
> But since it has nothing to do with the LDAP traffic, I don't want to
> change it now.
>
>> > [realms]
>> > SESSWIN2003.COM = {
>> > kdc = 13.198.98.35:88
>> ^^^^^^^^^^^^
>> Is that the IP address of your AD domain controller? Is
>> SESSWIN2003.COM your AD domain?
>
> Yes, this is the IP address of the AD domain controller. And Yes again,
> SESSWIN2003.COM is my AD domain.
>
>> > durian.fujixerox.com = {
>> > kdc = kerberos.durian.fujixerox.com:88
>> > admin_server = kerberos.durian.fujixerox.com:749 }
>>
>> Likely you should remove that.
>>
>> You should try to find a working setup with AD using your
>> favourite search engine. Please read a little bit more what
>> the different parameters really mean.
>
> Thanks a lot,
> Xu Qiang
>
> ________________________________________________
> Kerberos mailing list Kerb...@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
Markus
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Markus Moeller
> Sent: Wednesday, March 25, 2009 7:53 AM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
> nslookup sesswin2003.com or add a search path to your
> resolv.conf file (e.g. search
> sesswin2003.com)
Yesterday, my resolve.conf was like this:
=================================
search sgp.fujixerox.com sesswin2003.com
nameserver 13.198.8.83
nameserver 13.198.96.10
nameserver 13.198.98.35
=================================
To my dismay, it didn't work. The hostname "sesswin2003" still couldn't be resolved to its IP address.
Today, with the help of our local SA, the file is changed to:
=================================
search sgp.fujixerox.com sesswin2003.com
nameserver 13.198.98.35
nameserver 13.198.96.10
=================================
It seems the order of nameserver list is important. Quite strange. Or it may be the problem of some DNS server. Because if I put the nameserver 13.198.96.10 in front of 13.198.98.35, it still doesn't work. By right, if a hostname can't be located by the first nameserver, it should continue to look for the hostname in the second nameserver, right?
Anyway, now nslookup works perfectly:
=================================
qxu@durian(pts/1):/etc[17]$ nslookup sesswin2003
Server: 13.198.98.35
Address: 13.198.98.35#53
Name: sesswin2003.sesswin2003.com
Address: 13.198.98.35
qxu@durian(pts/1):/etc[18]$ nslookup sesswin2003.sesswin2003.com
Server: 13.198.98.35
Address: 13.198.98.35#53
Name: sesswin2003.sesswin2003.com
Address: 13.198.98.35
=================================
For me, it is quite promising.
Then I did what Michael and Doug told me, i.e. kinit, klist and ldapsearch:
=================================
qxu@durian(pts/1):/etc[19]$ kinit q...@SESSWIN2003.COM
Password for q...@SESSWIN2003.COM:
qxu@durian(pts/1):/etc[20]$ klist
Ticket cache: FILE:/tmp/krb5cc_20153
Default principal: q...@SESSWIN2003.COM
Valid starting Expires Service principal
03/25/09 17:21:13 03/26/09 03:21:11 krbtgt/SESSWIN...@SESSWIN2003.COM
renew until 03/26/09 17:21:13
Kerberos 4 ticket cache: /tmp/tkt20153
klist: You have no tickets cached
qxu@durian(pts/1):/etc[21]$ ldapsearch -Y GSSAPI -H 'ldap://sesswin2003.sesswin2003.com' -b 'dc=sesswin2003,dc=com' -s sub -LLL 'cn=xuan' mail
SASL/GSSAPI authentication started
SASL username: q...@SESSWIN2003.COM
SASL SSF: 56
SASL installing layers
dn: CN=xuan,CN=Users,DC=sesswin2003,DC=com
mail: Xuan.Sh...@fujixerox.com
# refldap://ForestDnsZones.sesswin2003.com/DC=ForestDnsZones,DC=sesswin2003,D
C=com
# refldap://DomainDnsZones.sesswin2003.com/DC=DomainDnsZones,DC=sesswin2003,D
C=com
# refldap://sesswin2003.com/CN=Configuration,DC=sesswin2003,DC=com
=================================
It works perfectly. Next I will use this as a bench against my own coding.
Thanks to all,
Xu Qiang
Markus Moeller
"Xu, Qiang (FXSGSC)" <Qian...@fujixerox.com> wrote in message
news:D8C9BC7FFCF8154FB7141...@SGPAPHQ-EXSCC01.dc01.fujixerox.net...
>> From: kerberos...@mit.edu
>> [mailto:kerberos...@mit.edu] On Behalf Of Markus Moeller
>> To: kerb...@mit.edu
>> Subject: Re: SASL authentication
>>
>> nslookup sesswin2003.com or add a search path to your
>> resolv.conf file (e.g. search
>> sesswin2003.com)
>
> Yesterday, my resolve.conf was like this:
> =================================
> search sgp.fujixerox.com sesswin2003.com
> nameserver 13.198.8.83
> nameserver 13.198.96.10
> nameserver 13.198.98.35
> =================================
> To my dismay, it didn't work. The hostname "sesswin2003" still couldn't be
> resolved to its IP address.
>
> Today, with the help of our local SA, the file is changed to:
> =================================
> search sgp.fujixerox.com sesswin2003.com
> nameserver 13.198.98.35
> nameserver 13.198.96.10
> =================================
> It seems the order of nameserver list is important. Quite strange. Or it
> may be the problem of some DNS server. Because if I put the nameserver
> 13.198.96.10 in front of 13.198.98.35, it still doesn't work. By right, if
> a hostname can't be located by the first nameserver, it should continue to
> look for the hostname in the second nameserver, right?
>
No it wouldn't. If the first server says unknown domain it is a valid
reponse and the next server wouldn't be queried. Only if the first server
does not reply the second will be used (afaik)
> Anyway, now nslookup works perfectly:
> =================================
> qxu@durian(pts/1):/etc[17]$ nslookup sesswin2003
> Server: 13.198.98.35
> Address: 13.198.98.35#53
>
> Name: sesswin2003.sesswin2003.com
> Address: 13.198.98.35
>
> qxu@durian(pts/1):/etc[18]$ nslookup sesswin2003.sesswin2003.com
> Server: 13.198.98.35
> Address: 13.198.98.35#53
>
> Name: sesswin2003.sesswin2003.com
> Address: 13.198.98.35
> =================================
> For me, it is quite promising.
>
> Then I did what Michael and Doug told me, i.e. kinit, klist and
> ldapsearch:
> =================================
> qxu@durian(pts/1):/etc[19]$ kinit q...@SESSWIN2003.COM
> Password for q...@SESSWIN2003.COM:
>
> qxu@durian(pts/1):/etc[20]$ klist
> Ticket cache: FILE:/tmp/krb5cc_20153
> Default principal: q...@SESSWIN2003.COM
>
> Valid starting Expires Service principal
> 03/25/09 17:21:13 03/26/09 03:21:11
> krbtgt/SESSWIN...@SESSWIN2003.COM
> renew until 03/26/09 17:21:13
>
>
> Kerberos 4 ticket cache: /tmp/tkt20153
> klist: You have no tickets cached
>
> qxu@durian(pts/1):/etc[21]$ ldapsearch -Y GSSAPI -H
> 'ldap://sesswin2003.sesswin2003.com' -b 'dc=sesswin2003,dc=com' -s
> sub -LLL 'cn=xuan' mail
> SASL/GSSAPI authentication started
> SASL username: q...@SESSWIN2003.COM
> SASL SSF: 56
> SASL installing layers
> dn: CN=xuan,CN=Users,DC=sesswin2003,DC=com
> mail: Xuan.Sh...@fujixerox.com
>
> #
> refldap://ForestDnsZones.sesswin2003.com/DC=ForestDnsZones,DC=sesswin2003,D
> C=com
>
> #
> refldap://DomainDnsZones.sesswin2003.com/DC=DomainDnsZones,DC=sesswin2003,D
> C=com
>
> # refldap://sesswin2003.com/CN=Configuration,DC=sesswin2003,DC=com
> =================================
> It works perfectly. Next I will use this as a bench against my own coding.
>
> Thanks to all,
> Xu Qiang
Xu, Qiang (FXSGSC)
> From: kerberos...@mit.edu
> [mailto:kerberos...@mit.edu] On Behalf Of Markus Moeller
> Sent: Thursday, March 26, 2009 5:43 AM
> To: kerb...@mit.edu
> Subject: Re: SASL authentication
>
>
> > the nameserver 13.198.96.10 in front of 13.198.98.35, it still
> > doesn't work. By right, if a hostname can't be located by the first
> > nameserver, it should continue to look for the hostname in the
> > second nameserver, right?
>
> No it wouldn't. If the first server says unknown domain it is
> a valid reponse and the next server wouldn't be queried. Only
> if the first server does not reply the second will be used (afaik)
Now my resolve.conf is as follows:
================================
search sgp.fujixerox.com sesswin2003.com
nameserver 13.198.98.35
nameserver 13.198.96.10
================================
The machine "durian" can only be resolved by "13.198.98.10".
This is the result of nslookup:
================================
qxu@durian(pts/1):~[5]$ nslookup durian
Server: 13.198.96.10
Address: 13.198.96.10#53
Non-authoritative answer:
Name: durian.sgp.fujixerox.com
Address: 13.198.98.190
================================
Why doesn't it go to the first nameserver (13.198.98.35) to try to resolve "durian"? 13.198.98.10 is the second server.
And I can verify the first server is alive and working:
================================
qxu@durian(pts/1):~[6]$ nslookup sesswin2003
Server: 13.198.98.35
Address: 13.198.98.35#53
Name: sesswin2003.sesswin2003.com
Address: 13.198.98.35
================================
So if the first server is alive, when the request to resolve "durian" arrives, the first nameserver (13.198.98.35) should be queried. Is it? But in fact, the first server was skipped, and the query was done with the second server. How to explain this behavior?
Thanks,
Xu Qiang