[6.200] Novell eDirectory Howto

Hi Sven, 

In order to help Novell Customers get up to speed with our new features, 
we created a Wiki with all relevant informations:
http://nsm-wiki.astaro.com

In your case i am surprised that it staies empty.

For the eDirectory browser to work, 
you need to configure the IP/Port/SSL settings.
the Context is optional and is only used for the actual authentication.

If you entered this information and start the eDir Browser, the WebGUI will create an anonymous ldap bind to your edirectory, 
trying to read the tree structure.

If your access control of your eDirectory does not allow an anonymous bind to read everything, 
you need to 
- enable "SSO"
- enter BindDN and password, which is able to read the structure
- disable "SSO"

than the next time you open the eDir Browser, it will use this BaseDN to connect the eDirectory.

I suggest that you add a specific "ASG user" that only is allowed to read the tree and use that one.

Hope this helps, 
regards

Gert

Hi Gert, 
thanks for the Reply. Enabling SSO with
a user helped (cn=,o=)

Thanks a lot...

Beside that:
At the moment you click the button "Browse eDirectory" you will see some rudimentary informations in the logfile /var/log/httpd.log ("HTTP daemon" in Webadmin). At least you should see a message "Can't connect!", if the problem is related to the connection itself.

Xeno

For the authentication I found something
in /var/log/aua.log

For now I am trying to get SSO (Single Sign On) to work.
Does someone know if there are special Client Properties needed?
I have never used SSO before, does NMAS have to be installed?

Hi Sven, 

In order to use SSO you do not need any additonal software on the clients besides the regular Netware Client.
So you do  NOT need Client trust (CLNTRUST) or NMAS or NICI or any other Novell software.

Just eDirectory and a Netware Client.

How does the SSO work?
I posted a basic explanation here:
http://nsm-wiki.astaro.com/wiki/FAQ_for_Novell_users

Please let me know it works?

thx Gert

Mmmhhh...
do not get it to work. If I enable SSO in HTTP Proxy for example,
I still get the Proxy Authentication Dialog (in Firefox).
If I enter my username and password I am able to use the proxy
(but this is not SSO I think)...

aua.log says:
2006:03:22-15:12:18 (none) aua[6924]: do_auth_edir() eDirectory Authentication failed - user '192.168.X.XXX' or password not valid
2006:03:22-15:12:18 (none) aua[6924]: U:192.168.X.XXX F:http R[:D]ENIED C:edir
2006:03:22-15:12:18 (none) aua[2554]: U:USERNAME F:http R[:$]K [] C:cached

So it seems ASG first tries the SSO and this fails. Then it uses the normal Authentication.... ???

Maybe the problem is that client is installed IPX only?

Hi,

seems the "SSO bind user" does not have permission to search for the IP address in the eDirectory. Do you have a "SSO bind user" set? Are you able to see all objects by using the eDirectory Browser?

Xeno

> Maybe the problem is that client is installed IPX only? 
>do_auth_edir() eDirectory Authentication failed - user '192.168.X.XXX' or

Whose IP address is that? It should be the IP address of the Novell Client Machine.

Xeno

Hi,
I have the exact same problem.
At the moment, my SSO bind user is the admin user itself.
I'm able to browse eDirectory objects, although it seems kind of slow. Maybe there's some kind of timeout envolved.
I hope someone will find a fix, I could really use it.
Thanks

Hi Xeno, tried some things:

- Installed a machine with an IP-Only Client -> no change
- The IP Adress I see in the AUA.LOG is the IP Adress of the machine which tries to use the Proxy -> so this is correct
- I have a special SSO User Created to connect to the eDirectory, for testing purposes I used "admin" to see if I configured the wrong user but the user seems to be correct

I will check if I can get something via DSTRACE...


cu SveN

Here is the DSTRACE:

 Code:

---

 New TLS connection 0x60e7c380 from 192.168.X.YYY:56349, monitor = 0x204, index = 3



Monitor 0x204 initiating TLS handshake on connection 0x60e7c380

DoTLSHandshake on connection 0x60e7c380                                         

Completed TLS handshake on connection 0x60e7c380                                

DoBind on connection 0x60e7c380                                

Bind name:cn=192.168.X.XXX,o=CONTEXT, version:3,authentication:simple

17:02:36

Failed to resolve full context on connection 0x60e7c380, err = no such entry (-601)

Failed to authenticate full context on connection 0x60e7c380, err = no such entry (-601)                                                                        

Sending operation result 32:"":"NDS error: no such entry (-601)" to connection 0x60e7c380                                                                       

TLS read failure 5 on connection 0x60e7c380, setting err = -5875. Error stack:  

Monitor 0x204 found connection 0x60e7c380 socket failure, err = -5875, 0 of 0 bytes read                                                                        

Monitor 0x204 initiating close for connection 0x60e7c380                        

Server closing connection 0x60e7c380, socket error = -5875                      

Connection 0x60e7c380 closed    

---

 

Does not look very good.... anyone an idea???

Here is the DSTRACE:

 Code:

---

 New TLS connection 0x60e7c380 from 192.168.X.YYY:56349, monitor = 0x204, index = 3



Monitor 0x204 initiating TLS handshake on connection 0x60e7c380

DoTLSHandshake on connection 0x60e7c380                                         

Completed TLS handshake on connection 0x60e7c380                                

DoBind on connection 0x60e7c380                                

Bind name:cn=192.168.X.XXX,o=CONTEXT, version:3,authentication:simple

17:02:36

Failed to resolve full context on connection 0x60e7c380, err = no such entry (-601)

Failed to authenticate full context on connection 0x60e7c380, err = no such entry (-601)                                                                        

Sending operation result 32:"":"NDS error: no such entry (-601)" to connection 0x60e7c380                                                                       

TLS read failure 5 on connection 0x60e7c380, setting err = -5875. Error stack:  

Monitor 0x204 found connection 0x60e7c380 socket failure, err = -5875, 0 of 0 bytes read                                                                        

Monitor 0x204 initiating close for connection 0x60e7c380                        

Server closing connection 0x60e7c380, socket error = -5875                      

Connection 0x60e7c380 closed    

---

 

Does not look very good.... anyone an idea???

I had the exact same problem with the SSO.  My BIND DN was that of my IP address instead of the BIND user/pass specified under SSO.  After the upgrade to 6.200 the server didn't restart, I manually restarted the server and it started binding correctly and SSO began working.

Hi,

I think my Problem is  this

But I do not know where NDSSchema.exe is located...?

cu SveN

I don't think that this is your problem.
I have Novell Secure Login installed, and schema has been extended however - the same problem.
I should point out that SSO sometimes works on my network. That happens if I manually assign an IP address and restart a workstation. Than eDirectory stores that different address and it works but when I leave the address acquired by DHCP, I get User Authentication prompt in 99% cases. And even when it doesn't prompt for authentication it sometimes does "single sign on" but proxy thinks I'm a different user because someone else used that very address before and it was stored also under that different user in eDirectory (properties of the user->general->environment->network address).

Hi vdrdr,

Do you have multiple Novell Servers? Maybe the NDS Synchronisation between the Servers does not work correctly?

cu SveN

I do have multiple Novell servers, but I don't think there's a problem with synchronisation. I would probably notice somewhere else.
EDirectory just stores multiple IP addresses for users that sometimes change IP address. But I must stress that SSO doesn't work in most cases, even when a user has only one IP address stored.
ASL uses SSL to comunicate with eDirectory and when I switch to port 389, eDirectory browsing simply doesn't work from ASL although it is otherwise functional.

Hi!
My SSO seems to work! I guess SveN was partially right. Multiple IP addresses stored in a user environment properties have been cleaned by DSRepair but synchronisation was fine.
I'll post again if something new happens.

Keep in mind, there is a 5 minute cache. Astaro caches 5 minutes the result of the request to the eDirectory. So, if an IP address was allowed by SSO, it will be allowed for 5 more minutes. Also, if another users has logged in on the machine, in the meantime.
To empty the cache for testing execute ' /etc/rc.d/aua restart; /var/mdw/scripts/hyperdyper.sh restart' on console.

Xeno

Hi there all, 

i was just talking to Sven and i might have found a hint, why some Netware client's don't want to authenticate.

We use the "IP only"-version of the Netware Client, and with this one SSO works fine.

If you are using the "IPX only"-version of the Netware Client, than SSO might not work, as the client stores the IPX address in the eDirectory and not the IP Address. Therefor we can not authenticate the IP address.

Can you confirm this, means do you have an IPX-only client that is not working and the IP-only client is working?

Thx Gert

Hi!
We have all clients configured to IP-only and still had a problem. We have multiple Novell server environment and synchronisation between eDirectory replicas was fine. However, eDirectory stored multiple IP addresses for the same user if the user's workstation changed IP addresses or if the user logged on different WSs.
I'm not 100% convinced that that was the problem but after DSRepair my eDirectory cleaned "wrong" IP addresses and now SSO works fine!

Hi Gert,
 [ QUOTE ]
 Can you confirm this, means do you have an IPX-only client that is not working and the IP-only client is working? 

[/ QUOTE ] 
Yes I can confirm this. The IPX client stores an IPX Address into the LDAP User Opject and the IP Client stores the IP Address....

Means: No Luck with SSO and IPX Clients....  [:(]