eDirectory SSO

It is very straight forward. I hope you are not using IPX in your network because it will not work with that. Just use the ipaddress of the server you want to do sso with. I recommend leaving it set to secure on 636. give a user who can access the directory. It works very well and have had no issues with it.

I figured out the IPX part the hard way and thought I had it at that point.

I have checked ldap using an ldap search tool and the bind user works properly. I am using port 636.

The problem seems to be SSO and not really edirectory since a user can log through the challenge prompt and authenticate to edirectory and the browsing rules based on their group membership is applied correctly.

Two things happen that don't make sense to me.

1. I have seen users get a challenge prompt at one pc and then log in on the pc right beside it and successfully authenticate without a challenge prompt. I thought IP only would resolve this but it didn't.

2. I have authenticated a user and had them stay authenticated no matter who signed in after them.

Not sure why either is happening. Ver frustrating...

Which version are you testing?  Version 7.100 has fixed a lot of issues with Edirectory.

I was to 7.091 but I upgraded to 7.100 at hte end of the day today. I will try again on Wed. with the new firmware.

Couldn't wait..tested just now and I get a challenge prompt...

Two thoughts... When I look at my connection using netware "monitor", I see some users appear as Normal and others as Authenticated. Could this be a problem and if so any idea what normal means for someone who is logged in and why are they not authenticated.

Second is also in the monitor>connections, the ip reads as ***.***.***.***[:P]ort. I read a thread about this being a problem as the port # is being passed as the part of the network address and the ASG has trouble with the format...

Shots in the dark but you never know..

Thanks,

Chris

Do you have a license w/ maintenance? This sounds like something that might need a support case opened on it.  If you don't have maintenance, and are evaluating, see if your reseller will open a case for you... I do that all the time for potential customers during their evaluations.

I have Gold maintenance but support has not been able to figure it out... which is why I started looking at edirectory for answers...

did tried calling 1/2 hour ago and phone rings off the hook-- no answer... wonderful support i'm paying for.[:@] 

If it is as simple as:

-http request comes from ip address 192.168.4.50
-Astaro performs ldap lookup to see who is authenticated with 192.168.4.50
-if ldap database search finds a user with that address then browsing is granted based on that users group membership.

then there is no reason for it to not work unless:
the http request is somehow malformed without an ip address (i deifinitely had this problem with ipx earlier),

or the ldap database does not have username and ip address information in the table so this connection can be made.

or the Astaro does not successfully perform an ldap search.

in either case I would think that Astaro support would be able to tell from the logs where the disconnect is but so far no ne has been able to help.

Thanks

Chris

ldap search show user object as:

Enumerating attributes for DN : cn=toc,ou=Teachers,ou=Users,o=VES 
messageServer = cn=VES,ou=Servers,o=VES
sn = TOC
securityEquals = cn=Teacher,ou=Groups,o=VES
passwordRequired = TRUE
passwordMinimumLength = 4
objectClass = inetOrgPerson
objectClass = organizationalPerson
objectClass = person
objectClass = ndsLoginProperties
objectClass = top
networkAddress = 1#À¨!
loginTime = 20071204202035Z
ndsHomeDirectory = cn=VES_VOL1,ou=Servers,o=VES#0#/home/Teachers\toc
groupMembership = cn=Teacher,ou=Groups,o=VES
cn = toc
ACL = 2#subtree#cn=toc,ou=Teachers,ou=Users,o=VES#[All Attributes Rights]
ACL = 6#entry#cn=toc,ou=Teachers,ou=Users,o=VES#loginScript
ACL = 2#entry#[Public]#messageServer
ACL = 2#entry#[Root]#groupMembership
ACL = 6#entry#cn=toc,ou=Teachers,ou=Users,o=VES#printJobConfiguration
ACL = 2#entry#[Root]#networkAddress


Is network address always encoded? networkAddress = 1#À¨! or is this why astaro can't make the address=user association using ldap?

Seems to be encoded like this on two different networks that I have looked at.

Hi sd48tech, I've spent an inordinate amount of time with Astaros and Edir. First, what version of Edirectory are you running? What Novell client version? If you open console one and look in the "environment" part of the "general" tab of a user do you see an IP in the Network Address field? This is what the Astaro uses to authenticate using SSO, if this field is not populated with an IP you have a Netware issue, if it is then you need to look at the Astaro. Edirectory 8.7.3.9 or later is prefferable and Novell Cient 4.91 sp3 or 4 are the only clients that really handle SSO well. I'm assuming that when you configure your users/groups under "authentication" you are able to browse your Edirectory tree from the Astaro console?

Hi sd48tech, I've spent an inordinate amount of time with Astaros and Edir. First, what version of Edirectory are you running? What Novell client version? If you open console one and look in the "environment" part of the "general" tab of a user do you see an IP in the Network Address field? This is what the Astaro uses to authenticate using SSO, if this field is not populated with an IP you have a Netware issue, if it is then you need to look at the Astaro. Edirectory 8.7.3.9 or later is prefferable and Novell Cient 4.91 sp3 or 4 are the only clients that really handle SSO well. I'm assuming that when you configure your users/groups under "authentication" you are able to browse your Edirectory tree from the Astaro console?