Authenticating Linux to e-Directory
cstu...@nospam.jwortham.com
I have been using Jeffrey Brown and Jeff Flagout's Cool Solutions
article as a guide to get Linux workstations to authenticate to
e-Directory in a test lab and can't seem to get it working.
The test lab hardware consists of the following:
1 - Netware 6SP3 Server - Fresh Install running E-Directory 8.7.1
2 - Linux workstations - Redhat 8.- All patches and updates.
1 - Windows 2000 SP3 workstation to run iManager 1.5.2/Console 1.3.6
When the user tries to login to the Linux workstation a connection is
made to the Ldap server on and a successful lookup occurs. There
appears to be some kind of problem with sending/receiving/comparing
the password between the linux box and the Novell Ldap server.
Has anyone succesfully used the two Jeffs article to get this going?
What prerequisite am I missing that is not listed in the article?
This is a DSTRACE log. I could not find anything on the -5875 error on
the Novell support site.
====================================================
New cleartext connection 0xcb5d74a0 from 192.168.1.11:32931, monitor =
0x219, index = 6
Implied anonymous bind by operation 0x1:0x77 on connection 0xcb5d74a0
DoExtended on connection 0xcb5d74a0
Start TLS request issued from connection 0xcb5d74a0
Sending operation result 0:"":"" to connection 0xcb5d74a0
Monitor 0x219 initiating TLS handshake on connection 0xcb5d74a0
DoTLSHandshake on connection 0xcb5d74a0
Completed TLS handshake on connection 0xcb5d74a0
DoBind on connection 0xcb5d74a0
Treating simple bind with empty DN and no password as anonymous
Bind name:NULL, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0xcb5d74a0
DoSearch on connection 0xcb5d74a0
Search request:
base: "o=wortham"
scope:2 dereference:0 sizelimit:1 timelimit:0 attrsonly:0
filter: "(uid=jsmith)"
no attributes
Empty attribute list implies all user attributes
Sending search result entry "cn=jsmith,o=wortham" to connection
0xcb5d74a0
Sending operation result 0:"":"" to connection 0xcb5d74a0
DoBind on connection 0xcb5d74a0
Bind name:cn=jsmith,o=wortham, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0xcb5d74a0
DoBind on connection 0xcb5d74a0
Treating simple bind with empty DN and no password as anonymous
Bind name:NULL, version:3, authentication:simple
Sending operation result 0:"":"" to connection 0xcb5d74a0
DoSearch on connection 0xc90b52e0
Search request:
base: "o=wortham"
scope:2 dereference:0 sizelimit:1 timelimit:0 attrsonly:0
filter: "(&(objectclass=posixAccount)(uid=jsmith))"
attribute: "uid"
attribute: "userPassword"
attribute: "uidNumber"
attribute: "gidNumber"
attribute: "cn"
attribute: "homeDirectory"
attribute: "loginShell"
attribute: "gecos"
attribute: "description"
attribute: "objectClass"
Sending search result entry "cn=jsmith,o=wortham" to connection
0xc90b52e0
Sending operation result 0:"":"" to connection 0xc90b52e0
Monitor 0x219 found connection 0xcb5d74a0 ending TLS session
TLS read failure 5 on connection 0xc90b52e0, setting err = -5875.
Error stack:
Monitor 0x219 found connection 0xc90b52e0 socket failure, err = -5875,
0 of 0 bytes read
Monitor 0x219 initiating close for connection 0xc90b52e0
DoUnbind on connection 0xcb5d74a0
Preempting operation 0x0:0x3 on connection 0xcb5d74a0 before
processing because connection is closing
Connection 0xcb5d74a0 closed
Server closing connection 0xc90b52e0, socket error = -5875
Connection 0xc90b52e0 closed
====================================================
------------------------------------------
If its not on fire its a software problem!
------------------------------------------
Remove Nospam to reply.
Michael Krzyzanski
I´m a newbie in Linux and also not very much with Netware but have you
choose the Option save Passwords at the LDAP Tag during the Netware
Installation?
The Connection below is a cleartext connection, as I know you have to
allow the NW Server to work with cleartext passwords with LDAP.
Hope this helps, somehow.
Bye
Michael
Jim Henderson [SysOp]
cleartext, and that should be OK - but a TLS negotiation takes place later
on in the trace. :-)
Jim
--
Jim Henderson, Novell Support Connection Volunteer SysOp
http://support.novell.com/forums
(Sorry, support is not provided via e-mail)
Homepage at http://hendersj.dyndns.org (URL has changed!)
Jim Henderson [SysOp]
to run PKIDiag against the server (assuming it's a NW server here) and see
what it reports back.
cstu...@nospam.jwortham.com
<Jim.He...@SysOps.NSC> wrote:
>Looks like something's going wrong with the TLS connection - you may want
>to run PKIDiag against the server (assuming it's a NW server here) and see
>what it reports back.
>
>Jim
Sorry for the delay. I have been out of for the last week....
I downloaded PKIDiag from the support site and ran it. It found a
problem right away. It reported:
=========================================
PROBLEM: The KMO 'IP AG 192\.168\.1\.10 - NW6TEST.wortham does not
have the right naming convention.
UNFIXABLE: !!! This utilitiy cannot fix this kind of problem !!!
KMO IP AG 192\.168\.1\.10 - NW6TEST.wortham is linked.
=========================================
I loaded pkidiag with the /forcenew option to have it recreate the KMO
objects. Here is the PKIDIAG.LOG entries after the recreate.
============================================
---------------------------------------------------------------------------
NPKIRepair Starting (Check the end of the log for the last repair
results)
Current Time: Tue Sep 9 14:16:49 2003
User logged-in as: admin.wortham.
Diagnostics only mode
--> Server Name = 'NW6TEST'
---------------------------------------------------------------------------
Step 1 Verifying the Server's link to the SAS Service Object.
Server 'NW6TEST.wortham' points to SAS Service object 'SAS Service
- NW6TEST.wortham'
Step 1 succeeded.
Step 2 Verifying the SAS Service Object
SAS Service object 'SAS Service - NW6TEST.wortham' is backlinked to
server 'NW6TEST.wortham'.
Step 2 succeeded.
Step 3 Verifying the links to the KMOs
Reading the links for SAS Service object 'SAS Service -
NW6TEST.wortham'.
--->KMO SSL CertificateIP - NW6TEST.wortham is linked.
--->KMO SSL CertificateDNS - NW6TEST.wortham is linked.
--->KMO NAASKMO - NW6TEST.wortham is linked.
--->KMO IP AG 1 - NW6TEST.wortham is linked.
--->KMO DNS AG - NW6TEST.wortham is linked.
Step 3 succeeded.
Step 4 Verifying the KMOs
---> Testing KMO 'DNS AG - NW6TEST.wortham'.
Rights check -- OK.
Back link -- OK.
Private Key -- OK.
---> Testing KMO 'IP AG 1 - NW6TEST.wortham'.
Rights check -- OK.
Back link -- OK.
Private Key -- OK.
---> Testing KMO 'NAASKMO - NW6TEST.wortham'.
Rights check -- OK.
Back link -- OK.
Private Key -- OK.
---> Testing KMO 'SSL CertificateDNS - NW6TEST.wortham'.
Rights check -- OK.
Back link -- OK.
Private Key -- OK.
---> Testing KMO 'SSL CertificateIP - NW6TEST.wortham'.
Rights check -- OK.
Back link -- OK.
Private Key -- OK.
Step 4 succeeded.
Step 5 Re-verifying the links to the KMOs
Reading the links for SAS Service object 'SAS Service -
NW6TEST.wortham'.
KMO 'SSL CertificateIP - NW6TEST.wortham' is linked.
KMO 'SSL CertificateDNS - NW6TEST.wortham' is linked.
KMO 'NAASKMO - NW6TEST.wortham' is linked.
KMO 'IP AG 1 - NW6TEST.wortham' is linked.
KMO 'DNS AG - NW6TEST.wortham' is linked.
Step 5 succeeded.
Step 6 Creating IP and DNS Certificates if necessary.
--> Number of Server IP addresses = 1
--> The default IP address is: 192.168.1.10
--> The KMO SSL CertificateIP's IP Address is:
192.168.1.10.O=.TWORTHAM.
----> The IP addresses match.
--> Number of Server DNS names for the IP address 192.168.1.10 = 1
--> The server's default DNS name is:
nw6test.jwortham.com
--> The KMO SSL CertificateDNS's DNS name is:
nw6test.jwortham.com.O=.TWORTHAM.
----> The DNS names match.
Step 6 succeeded.
Note: Occasionally multiple problems will be solved with a single fix.
Fixable problems found: 0
Problems fixed: 0
Un-fixable problems found: 0
============================================
I am still getting the TLS read failure 5 on connection 0xc90b52e0,
setting err = -5875. When the linux workstation ties to login.
Any more ideas?
cstu...@nospam.jwortham.com
>
>I have been using Jeffrey Brown and Jeff Flagout's Cool Solutions
>article as a guide to get Linux workstations to authenticate to
>e-Directory in a test lab and can't seem to get it working.
>
>The test lab hardware consists of the following:
>
>1 - Netware 6SP3 Server - Fresh Install running E-Directory 8.7.1
>2 - Linux workstations - Redhat 8.- All patches and updates.
>1 - Windows 2000 SP3 workstation to run iManager 1.5.2/Console 1.3.6
>
>When the user tries to login to the Linux workstation a connection is
>made to the Ldap server on and a successful lookup occurs. There
>appears to be some kind of problem with sending/receiving/comparing
>the password between the linux box and the Novell Ldap server.
>
>Has anyone succesfully used the two Jeffs article to get this going?
>What prerequisite am I missing that is not listed in the article?
SUCCESS!!
I have successfully gotten a Linux workstation to use e-Dir 8.71
running on a Netware 6.0SP3 server, for authentication!
The Linux workstation user accounts reside ONLY in e-Dir. The only
account on the Linux workstation is the root account.
******************************************************************
The solution: There is a missing piece of information in Jeffrey
Brown's and Jeff Flagout's Cool Solutions article:
Three modifications need to be made to the LDAP Group Attribute
Mappings in e-Directory using ConsoleOne.
DELETE these two mappings
NDS Attribute LDAP Attribute
=============================
UID uidNumber
GID groupID
ADD these three mappings
NDS Attribute LDAP Attribute
=============================
loginShell loginShell
uidNumber uidNumber
gidNumber gidNumber
Unload and Reload the NLDAP.NLM on the Netware server or click the
"Refresh NLDAP Server Now" button on the general tab of the LDAP
server object in ConsoleOne.
******************************************************************
DSTRACE logs still show the TLS Read Failure 5 with a sockett err =
-5875
But the authentication and login process works.
I have been unable to find anything on the TLS Read failure 5 that
would appear to pertain to this scenario.
Next I'm going to see if it is possible to configure a Windows 2000 to
use LDAP authtentication....
Jim Henderson [SysOp]
to you on this issue.
I might be inclined to delete and recreate the KMOs by hand, it looks like
it might be a weird issue that pkidiag isn't picking up - maybe a broken
association between the KMO and the server.