I just installed 6.200. And tried to get it work with the eDirectory on our Novell 6.5 Server... (Use SSL, entered the context). But If I click on >Browse eDirectory
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.
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.
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).
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.
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?
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!
