| Author |
Topic: You cannot reach a Kerberized service with the IP Address |
|
authen
member
offline  |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
 |
|
|
| You cannot reach a Kerberized service with the IP Address |
This problem occurs because on the client side the system gets the TGS based on the Kerberized service principal name (SPN). As no service registered at KDC with the IP address, the TGS fails and client get an error.
So, when you try to access the Active Directory with LDP.exe, you cannot use the IP Address of the domain controller, you have to use the name (either host name or FQDN). For example,
Server: myAD.myCompany.com
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Note: In microsoft world, if you use IP Address instead, the Kerberos protocol fails but the connection is established with a weaker security protocol -- NTLM.
|
|
|
|
|
|
|
authen
member
offline  |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Error might occur #1 -- Synchronous |
Also, the Synchronous checkbox has to be checked, otherwise Kerberos protocol will not go through and you will see, on the client side, the following error:
res = ldap_bind(ld, 'NULL', <unavailable, 1158); // v.3
Error <-1>: ldap_bind() failed: Local Error
Server error: <empty>
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Error might occur #2 -- Port number rather than 389 |
389 is default port number for LDAP protocol and the SPN honors this default settings also. But if the LDAP service is running on non-default number, let's say 3389, what's going to happen?
Server: myAD.myCompany.com
Port: 3389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
You will get, on the client side, the following error:
res = ldap_bind_s(ld, 'NULL', <unavailable>, 1158); // v.3
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: NTLM authentication protocol used instead but the server failed to support it.
For non-default port number, the LDAP service's SPN which has 389 as default was not identified while LDP.exe requesting the service ticket. So, the Kerberos protocol fails and the connection is established with a weaker security protocol -- NTLM.
Note: The above obseration is viewed under LDP+AD2003+JRE1.5.0_07. The latest AD and JRE1.6.x may have resolved this problem.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Port number rather than 389 -- But the server support NTLM |
For the case of above, if the LDAP server supports NTLM. The the successful message will really trick you.
You will get, on the client side, the following message:
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='clientNameRegisteredOnAD'; Pwd= <unavailable>; domain = 'MYCOMPANY.COM'.}
Authenticated as dn:'clientNameRegisteredOnAD'.
It seems that login process went through via Kerbose protocol. But on the server's side, the client 'clientNameRegisteredOnAD' was actually authenticated by NTLM Protocol.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Error might occur #3 -- Use auth. identit box unchecked |
Also, the Use auth. identit checkbox has to be checked also, otherwise Kerberos protocol will not go through.
Server: myAD.myCompany.com
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
Use auth. identit: un-checked
User: testuser
Password: <password>
(box checked)Domain: MYCOMPANY.COM
You will get, on the client side, the following error:
res = ldap_bind_s(ld, 'testuser', <unavailable>, 1158); // v.3
Error <89>: ldap_bind_s() failed: Parameter Error.
Server error: <empty>
On the server side, no binding request was received.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Error might occur #4 -- Wrong password |
Also, if you provide a wrong password, the Kerberos protocol will not go through either.
Server: myAD.myCompany.com
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
Use auth. identit: checked
User: testuser
Password: <wrong password>
(box checked)Domain: MYCOMPANY.COM
You will get, on the client side, the following error:
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='testuser'; Pwd= <unavailable>; domain = 'MYCOMPANY.COM'.}
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: <empty>
On the server side, no binding request was received.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Error might occur #5 -- Wrong user identity |
Also, if you provide a wrong user identity, the Kerberos protocol will not go through either.
Server: myAD.myCompany.com
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
Use auth. identit: checked
User: wrongtestuser
Password: <password>
(box checked)Domain: MYCOMPANY.COM
You will get, on the client side, the following error:
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='wrongtestuser'; Pwd= <unavailable>; domain = 'MYCOMPANY.COM'.}
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: NTLM authentication protocol used instead but the server failed to support it.
On the server side, binding request was received but it used NTLM for SASL GSS-SPNEGO instead.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| Error might occur #6 -- Wrong format of user identity |
Also, if you provide an user identity with wrong format, the Kerberos protocol will not go through either.
Server: myAD.myCompany.com
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
Use auth. identit: checked
User: testuser@MYCOMPANY.COM
Password: <password>
(box checked)Domain: MYCOMPANY.COM
You will get, on the client side, the following error:
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='testuser@MYCOMPANY.COM'; Pwd= <unavailable>; domain = 'MYCOMPANY.COM'.}
Error <49>: ldap_bind_s() failed: Invalid Credentials.
Server error: NTLM authentication protocol used instead but the server failed to support it.
On the server side, binding request was received but it used NTLM for SASL GSS-SPNEGO instead.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| If everything goes right, what I can see? |
If all settings are correct as follows:
Server: myAD.myCompany.com
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
Use auth. identit: checked
User: testuser
Password: <password>
(box checked)Domain: MYCOMPANY.COM
You will get, on the client side, the following message:
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='testuser'; Pwd= <unavailable>; domain = 'MYCOMPANY.COM'.}
Authenticated as dn:'testuser'.
On the server side, binding request was received and it did use Kerberos for SASL GSS-SPNEGO.
|
|
|
|
|
|
|
authen
member
offline |
| |
| posts: |
36 |
| joined: |
08/07/2006 |
| from: |
San Diego, CA |
|
|
|
|
|
| SSO -- How can I use LDP to do Single Sign-On? |
Supposed that all settings are correct as follows:
Server: myAD.myCompany.com
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
Use auth. identit: checked
If you have successfully logged into your terminal already, let say with "testuser@MYCOMPANY.COM", then you do not need to type in the user identity and password again. You can just simply leave the 'User' and 'Password' as blank as follows:
User: <blank>
Password: <blank>
(box checked)Domain: MYCOMPANY.COM
The LDAP.exe will retrieve current user's credentials from the Kerberos Tickets Cache. You will get, on the client side, the following message:
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='NULL'; Pwd= <unavailable>; domain = 'MYCOMPANY.COM'.}
Authenticated as dn:'NULL'.
On the server side, binding request was received and it did use Kerberos for SASL GSS-SPNEGO for the current user.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| The Kerberos is too picky ......... |
Whoaaaa...... the Kerberos is too picky particularly for the error case #6:
testuser@MYCOMPANY.COM
Is not the very right format for Kerberos principal notation?
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
|
The server host name must be a FQDN. If you just provide a netBIOS name, the Kerberos protocol will not go through either.
Server: myAD
Port: 389
Bind Function Type: Generic
Bind method: SSPI
Synchronous: checked
Use auth. identit: checked
User: testuser
Password: <password>
(box checked)Domain: MYCOMPANY.COM
You will get, on the client side, the following:
res = ldap_bind_s(ld, NULL, &NtAuthIdentity, 1158); // v.3
{NtAuthIdentity: User='testuser'; Pwd= <unavailable>; domain = 'MYCOMPANY.COM'.}
Authenticated as dn:'testuser'.
On the server side, binding request was received but it used NTLM for SASL GSS-SPNEGO instead.
|
|
|
|
|
|
|
eLDAP
member
offline |
| |
| posts: |
107 |
| joined: |
08/02/2006 |
| from: |
Austin, TX |
|
|
|
|
|
| How about Softerra ldapbrowser? |
Softerra is underlyingly using same library as LDP.exe. The error cases are the same. Only difference is the UI presentation:
Other Credentials:
Mechanism: GSS Negotiate
Principal: <principal>
Password: <passoword>
where there is only one line for User and Domain information, called Principal. Thereafter,
If you want Kerberos authentication, you must type in:
Principal: testuser@MYCOMPANY.COM
otherwise, anything like
Principal: MYCOMPANY\testuser
or
Principal: testuser
will trigger the backup unsecured NTLM authentication protocol.
|
|
|
|
|
|
|
|
Email To Friend | 
Set Alert To This Topic
New Topic | 
Post Reply 
posted on: 01/13/2009 09:53:52 PM
Edit
Quote
Report
Profile
Reply