Duplicate user names in my eDirectory

Hello,

we have a ASG320 and plan to authenticate our 1000+ users using eDirectory backend authentication.

The problem: We have users with the same common name (CN) in different containers (OU), but we didn't run into trouble in the past as the users are unambiguously identified with their distinguished names (DN = CN + OU + O). Now with the ASG I see a problem as apparently the ASG creates local users usign just the CN as their username, and I don't know how the ASG handles duplicate users...

Has anybody experience with that? Is there any workaround or will I have to rename all duplicate CNs?

Thanks
Javier

I haven't tested it myself, but you shouldn't have to rename anyone.  I believe that the process which takes place is:

1.  Computer is configured with proxy settings to point to the ASG.
2.  User makes an HTTP request which is sent to the ASG.
3.  The ASG looks at the IP address that the request came from, and asks eDir: "Who is logged in at x.x.x.x?".
4.  eDir replies: "Oh, that's jsmith.users.ou1.o".
5.  ASG checks to see what group jsmith.users.ou1.o belongs to.
6.  ASG applies whatever filtering is applicable to jsmith.users.ou1.o based on group membership.

The above could be completely wrong, but that's basically how we have ours setup... you DO NOT want to create/cache the accounts locally on the ASG.  It will bog down Webadmin whenever you browse network definitions.

I haven't tested it myself, but you shouldn't have to rename anyone.  I believe that the process which takes place is:

1.  Computer is configured with proxy settings to point to the ASG.
2.  User makes an HTTP request which is sent to the ASG.
3.  The ASG looks at the IP address that the request came from, and asks eDir: "Who is logged in at x.x.x.x?".
4.  eDir replies: "Oh, that's jsmith.users.ou1.o".
5.  ASG checks to see what group jsmith.users.ou1.o belongs to.
6.  ASG applies whatever filtering is applicable to jsmith.users.ou1.o based on group membership.

The above could be completely wrong, but that's basically how we have ours setup... you DO NOT want to create/cache the accounts locally on the ASG.  It will bog down Webadmin whenever you browse network definitions.

I hope the ASG works like that, that would be quite smart.

But there is still a problem: what about logging into the user portal and logging in during VPN SSL remote access? There you log in with your user name, and so far I only managed to log in with my CN, what happens if there is another user with the same CN?

(By the way, thanks for your suggestion not to cache all the users in the ASG. We thought it would be good to cache them for faster login. And now it's too late, we already have the 1500+ objects in our network definition list... It will take us a while to delete them all one by one...)

I hope the ASG works like that, that would be quite smart.

But there is still a problem: what about logging into the user portal and logging in during VPN SSL remote access? There you log in with your user name, and so far I only managed to log in with my CN, what happens if there is another user with the same CN?

(By the way, thanks for your suggestion not to cache all the users in the ASG. We thought it would be good to cache them for faster login. And now it's too late, we already have the 1500+ objects in our network definition list... It will take us a while to delete them all one by one...)

Sorry, no idea about that... we only do the proxy side for eDir auth as we are a school district and have no need for students to VPN in.  :/

I know a little about eDir, but definitely not enough to know if the following works as well in eDir as with Active Directory.

Even in a school district, you would want to facilitate access to the User Portal for teachers and administrators with email.  In order to do that, the user must be established in the Astaro with a correct email address.  These people should each have a unique CN.  Prefetch the groups with teachers and administrators, and you're golden.

Cheers - Bob

The eDirectory authentication should work ok, even if several users have the same CN.

Note that the ASG is passed a username (CN) and a password (eDirectory bind password).

The ASG connects to the directory using the credentials configured in WebAdmin.
It then searches for users with the given username as CN.
Then it attempts to bind to the directory with the found DN and the given password. If this bind succeeds, then the ASG knows that the user is authenticated against the directory, and it also knows the correct DN.

@JavierC
If you need something to automatically remove all backend users (i.e. automatically created users), please send me a private message.

Some days ago, I had following situation: a user with a non-unique CN logged in using VPN SSL remote access. In the list of remote access online users the full name of the user was wrong, it was the full name of the other user with same CN:

  CN + password_user1 => fullname_user2.
  CN + password_user2 => ??? (I haven't tested it)

What I see is that the ASG doesn't handle non-unique CNs very well, so I think the best will be to completely avoid non-unique CNs.

Thanks for your help!

Javier

... so I think the best will be to completely avoid non-unique CNs.

If this is option for you then, yes, this is definitely the best way [:)]

cheers
robert