OK we're going round and round here. What you're describing cannot possibly work because it is not possible for UserA to validate UserB's password. The act of binding to the server is where that password validation happens.
What you more than likely have is a hardcoded account which does a search to find if the authenticating user actually exists in the directory, and then it retrieves the user's DN and does a second bind with that value plus the supplied password. This is a fairly common model and there's not really anything wrong with it. Putting the users in your AD is fine, though any resource on your network secured for Authenticated Users or Everyone will be open for them. You can remove these accounts from Domain Users, though as a starter. Thanks, Brian Desmond [email protected] w - 312.625.1438 | c - 312.731.3132 From: Joseph L. Casale [mailto:[email protected]] Sent: Friday, September 30, 2011 11:12 PM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD It's not my choice, it's the way the software works. So many opensource ldap based apps sh!t the bed in that respect. If you're checking for a user, let ->that user<- initiate the bind, if he can't even do than clearly he shouldn't get access, but most are designed to use one hard coded account to bind. That being said, now I have to create a series of accounts given to customers to use with this app. Those accounts shouldn't have any rights in AD whatsoever but I thought it might be easier to manage them this way. jlc From: Brian Desmond [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Friday, September 30, 2011 9:12 PM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD Still not making sense to me here. Any user in AD can bind to a DC with valid creds. No extra permissions needed. This dedicated bind account though, what does it do? Thanks, Brian Desmond [email protected]<mailto:[email protected]> w - 312.625.1438 | c - 312.731.3132 From: Joseph L. Casale [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Friday, September 30, 2011 8:43 PM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD Hey, Thanks for the reply. I should have been more specific, there is a dedicated bind account. It's the users that bind account is checking, they are in AD merely for the sake of unifying all the places I have accounts but have no use in AD or rights. This Linux based app will look here for them and verify the password. I could have it point to flat files but then I have two places to manage accounts. I just wondered how many perms I could remove from the user and still make it work... Thanks! jlc From: Brian Desmond [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Friday, September 30, 2011 6:23 PM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD A bind is always performed in the context of the user making the request. That means you need to provide no extra permissions for this to occur. If the credentials supplied are valid, the bind will succeed. For straight read, chances are your service account needs no extra permissions, but, you'd have to describe what you're actually doing to say for sure. Thanks, Brian Desmond [email protected]<mailto:[email protected]> w - 312.625.1438 | c - 312.731.3132 From: Joseph L. Casale [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Friday, September 30, 2011 6:25 AM To: NT System Admin Issues Subject: Migrating OpenLDAP users into AD I want to move some users from another directory that are only for for and external app that does ldap auth against a non-windows setup. The thought was (long term) to delegate control of an OU to a manager. Aside from a lengthy gpo, anyone know a source which outlines what permissions must at least remain for this account to perform that type function, the app will simply perform a bind from a service account and check the pass. Thanks! jlc ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected]<mailto:[email protected]> with the body: unsubscribe ntsysadmin ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
