Thanks. At least I can be righteously indignant. From: Brian Desmond [mailto:[email protected]] Sent: Monday, October 03, 2011 12:59 PM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD
Yeah pretty much. I've had a few ISVs that I've worked with to make their integration work right but they're few and far between. Thanks, Brian Desmond [email protected]<mailto:[email protected]> w - 312.625.1438 | c - 312.731.3132 From: Crawford, Scott [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Monday, October 03, 2011 12:33 PM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD Ahh. That makes sense. But, I'm still allowed to be annoyed that I have to hard code clear text credentials in some config file, right? From: Brian Desmond [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Monday, October 03, 2011 10:59 AM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD AD doesn't require it but generic LDAP directories usually do require a DN to bind with. ISVs use one code path to support AD and *LDAP (for better or worse) so that's why you get this. Thanks, Brian Desmond [email protected]<mailto:[email protected]> w - 312.625.1438 | c - 312.731.3132 From: Crawford, Scott [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Monday, October 03, 2011 10:37 AM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD RE: This is a fairly common model and there's not really anything wrong with it. Why is it such a common model? I see it a lot too, and it always frustrates me that they don't simply use the credentials supplied by the user to attempt to bind to AD. If it fails, obviously the credentials are wrong. Is the DN somehow needed to do the bind in the first place? I asked joe about this a few years ago and if I recall, he said it wasn't required (but, I may be mis-remembering.) From: Brian Desmond [mailto:[email protected]]<mailto:[mailto:[email protected]]> Sent: Saturday, October 01, 2011 11:33 AM To: NT System Admin Issues Subject: RE: Migrating OpenLDAP users into AD 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]<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 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]<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
