Ah - multirealm issues. I understand. Actually that support sucks in MIT/Heimdahl, Linux is just a victim of it. Of course the MIT response is simply.... Well just use one realm.
joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky Sent: Friday, May 21, 2004 6:32 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Anonymous bind You are of course right about LDAP being primary a directory and not authentication protocol, but Linux's support for multiple Kerberos realms is not good enough and it is what I have in my environment (two W2K3 forests with cross forest Kerberos trust). I would prefer using Kerberos for authentication, but there are cases when the overhead and complication of Kerberos for Linux client authentication is not worth it, as compared to LDAP authentication. As for open source LDAP synchronization tool: I am not aware of one. This is something I would really love to put my hands on. Commercial solutions exist, but not always you have the bucks for it. Guy On Thu, 2004-05-20 at 00:13, joe wrote: > Why use LDAP for Linux client authentication instead of Kerberos? I am > seriously asking. I don't know why someone would avoid an > authentication protocol for authentication and instead would use a > directory protocol for authentication. Especially when you have to go > through an extra step then to secure the communication. I don't really > even like that people do it for apps but if you have one application > running on one server handling multiple users, I can see the draw of LDAP Auth. > > I am not a huge fan of multiple directories that you have to keep synced. > The larger the environment more likely the better chance it is > something that would have to be done. The smaller the environment the > less things you want to have to deal with as they are less likely to > have the people to manage the syncing plus more than likely it means > yet another piece of software to do the syncing though I could be > completely wrong and there is a beautiful open source free directory syncer out there somewhere. > > joe > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guy > Teverovsky > Sent: Wednesday, May 19, 2004 2:26 PM > To: [EMAIL PROTECTED] > Cc: ADS Customer Feedback > Subject: RE: [ActiveDir] Anonymous bind > > Eric, > > It looks like I was not clear enough. See my comments below. > > And as others have already stated, the solution should be in the app's code. > The problem is that it's not always that easy to change the code even > if it's open source. > > Guy > > On Wed, 2004-05-19 at 14:50, Eric Fleischman wrote: > > I’m going to respectfully disagree with the approach being taken here. > > It is, IMHO, misguided. > > > > > > > > What has been described as a security hole (opening your AD for a > > subset of operations being allowed by ANONYMOUS) has somehow been > > justified in the OpenLDAP world. Make no mistake about it: anonymous > > is anonymous on any platform. Allowing ANONYMOUS to read from one > > directory vs. another is the same threat. Why they are being viewed > > is a mystery to me. > My point was that you are only syncing with OpenLDAP the > uid<->sAMAccountName(or upn) and user's Kerberos principal. > ACL-ing OpenLDAP to allow read access by attribute is one-liner. > > > > > > > > > That said, from an order of complexity perspective, a sync solution > > will be substantially harder to set up and maintain over the long > > haul. > Indeed. But it gives several advantages, like using the same OpenLDAP > for Linux clients logons, without tweaking AD's schema by installing > SFU (which is rather dumb and not flexible enough to my taste). What I > described might be a good solution for a small heterogeneous network. > In larger scale, I would not be even considering deploying an > application which by default does anonymous binds. > > > > If this were my project, I would do the following: > > > > 1) Flip 7th bit of dsHeuristics to 2, enabling the ability to > > have anonymous binds to the DS (part one of the solution) > > > > 2) We need to now ACL things to ANONYMOUS has access to the data > > required. Fundamentally, there are two approaches: > > > > a. Target the objects that your auth client will be searching > > (perhaps a single subtree under an OU) and grant ANONYMOUS the > > minimum required perms for it…my bet is that just read to a subset > > of attributes is sufficient. > only 2 attributes are needed. The equivalent of uid (sAMAccountName or > upn > ?) and userPassword. > > > > b. You can try to flip the reg value “EveryoneIncludesAnonymous” > > to 1 on a single DC and see if that satisfies your needs. > > NOTE: this approach, if it works, is particularly advantageous as it > > is localized to a single DC, IE only a subset of DCs would have > > increased abilities for ANONYMOUS. > > > > > > > > Many comments Guy made confuse me, especially this one: > > > > > You will definitely not want that in production > > > > So you want to have a second directory with ANONYMOUS able to read > > it, but not a single one? How is OpenLDAP with ANONYMOUS somehow > > different than AD with ANONYMOUS reads enabled? I fail to see the > > difference here. If your difference was the localization problem, my > > EveryoneInludesAnonymous solution might do that for you a bit more > > gracefully. > I was not aware of that approach and I stand corrected. Obviously > there is a good reason I am subscribed to this list - I learn something new every day. > Thanks guys ! > > > > > > > > I don’t recall all of the ACLs that Everyone has in 2k03 out of the > > box, but if there is a problem there send me a trace of a failure > > and I can show you what need change to make it work. I bet it is > > small though. > > > > > > > > ~Eric > > > > > > > > > > > > > > ____________________________________________________________________ > > __ > > > > From: [EMAIL PROTECTED] > > [mailto:[EMAIL PROTECTED] On Behalf Of Aitzol > > Naberan Burgaña > > Sent: Wednesday, May 19, 2004 1:47 AM > > To: [EMAIL PROTECTED] > > Subject: Re: [ActiveDir] Anonymous bind > > > > > > > > > > OK, I will try the second approach. > > So I have to copy (sync) all the AD data into my local openLDAP??? > > creating a local schema with the user info??? > > -- > > > > Aitzol Naberan Burgaña > > CodeSyntax > > [EMAIL PROTECTED] > > www.codesyntax.com > > Tel: 943 82 17 80 > > > > > > > > Guy Teverovsky(e)k dio: > > > > There are several solutions to that: > > > > 1) Grant Everyone read permissions (this object and all child > > objects) to the domain object. The drawbacks are obvious: you are > > opening a HUGE security hole. You will definitely not want that in production. > > > > 2) Setup OpenLDAP and sync the needed attributes from AD. From what > > I can find ( > > http://docs.opengroupware.org/Members/sim/ldap-notes/view > > ), you will need to use top, account and simpleSecurityObject > > objectClasses. > > userPassword attribute can be a pointer to the user's Kerberos > > principal in AD Kerberos realm in the following form: > > userPassword: [EMAIL PROTECTED] In that way you can allow > > anonymous searches in OpenLDAP while exposing the bare minimum data > > and yet authenticate the users through LDAP. > > What happens in such a configuration is something like this: > > > > 1) OpenGroupware binds anonymously to OpenLDAP and performs the > > search for user object. > > 2) After the user object is found, OpenGroupware tries to bind as > > user to OpenLDAP (you should configure SSL/TLS if you do not want > > the passwords to travel in clear text) > > 3) OpenLDAP proxies the authentication request and passes it to AD's > > Kerberos. > > 4) AD's KDC verifies the user/password and returns OK to OpenLDAP. > > 5) OpenLDAP lets the user bind to OpenLDAP and user is authenticated. > > > > As you can figure it out, this approach greatly depends on the size > > of your AD (I have tested this at a small size network when > > implementing single sign-on for Linux clients. Have no idea how it > > will behave, if at all, with larger than single site implementation. > > > > Have a look at the following link for a HOWTO I used: > > http://www.arayan.com/da/yazi/OpenAFS_Kerberos_5.html > > > > Again, I have not tested it with OG and the mentioned above > > objectClasses (I needed top, person and posixAccount), but I guess > > this should work the same. > > > > Guy > > > > On Tue, 2004-05-18 at 17:17, Aitzol Naberan Burgaña wrote: > > > > > It's not so easy rewrite the source code, I will need spend a lot > > > of time to understand the source and to change it. But I think > > > that I have to do it, and change the bind method (I think it will work...). > > > > > > OpenGroupware is for unix systems, you can learn more in > > > www.opengroupware.org > > > > > > Thanks > > > -- > > > Aitzol Naberan Burgaña > > > CodeSyntax > > > [EMAIL PROTECTED] > > > www.codesyntax.com > > > Tel: 943 82 17 80 > > > > > > > > > joe(e)k dio: > > > > > > > Ah. Interesting, so it sounds like they want to compare the > > > > hashes instead of actually use the authentication of the system. > > > > Well since it is OpenSource, that should be easy to rewrite and > > > > correct > huh. > > > > :o) > > > > > > > > You can open up the anonymous search but if they need to see the > > > > password, you are dead in the water right there. You either > > > > can't use AD, can't use that product, or you need to modify the > > > > authentication routines. > > > > > > > > I have never heard of that product, is it *nix only or do they > > > > have > > > > Win32 ports? > > > > > > > > joe > > > > > > > > > > > > > > > > ________________________________________________________________ > > > > __ > > > > __ > > > > From: [EMAIL PROTECTED] > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Aitzol > > > > Naberan Burgaña > > > > Sent: Tuesday, May 18, 2004 9:21 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: [ActiveDir] Anonymous bind > > > > > > > > > > > > I'm trying to authentificate OpenGroupware (open source > > > > groupware > > > > suite) against Active Directory. The problem is that > > > > OpenGroupware's authentification method is a litle bit curious: > > > > It tries to do an anonymous bind to the ldap server before it > > > > will try to bind as the user name supplied at the login prompt. > > > > Active Directory will allow an anonymous bind, so that part is > > > > successful, but it does not allow an anonymous search. I'm not > > > > sure where authentification fails, because I have read thet > > > > OpenGroupware search a password and when doesn't find it fails. > > > > > > > > -- > > > > Aitzol Naberan Burgaña > > > > CodeSyntax > > > > [EMAIL PROTECTED] > > > > www.codesyntax.com > > > > Tel: 943 82 17 80 > > > > > > > > > > > > joe(e)k dio: > > > > > > > > > Correct. > > > > > > > > > > Aitzol, what problem are you trying to solve? > > > > > > > > > > joe > > > > > > > > > > ______________________________________________________________ > > > > > __ > > > > > __ > > > > > From: [EMAIL PROTECTED] > > > > > [mailto:[EMAIL PROTECTED] On Behalf Of Brent > > > > > Westmoreland > > > > > Sent: Tuesday, May 18, 2004 8:41 AM > > > > > To: [EMAIL PROTECTED] > > > > > Subject: Re: [ActiveDir] Anonymous bind > > > > > > > > > > > > > > > I know that the unicodePwd attributes can never be read by way > > > > > of ldap, you will probably find that this is true for > > > > > userPassword also. > > > > > > > > > > http://support.microsoft.com/default.aspx?scid=kb;EN-US;269190 > > > > > > > > > > > > > > > On May 18, 2004, at 6:29 AM, Aitzol Naberan Burgaña wrote: > > > > > > > > > > Hi all > > > > > > > > > > How can I grant "read" access to userPasswor attribute? > > > > > > > > > > > > > > > Thanks > > > > > > > > > > -- > > > > > Aitzol Naberan Burgaña > > > > > CodeSyntax > > > > > [EMAIL PROTECTED] > > > > > www.codesyntax.com > > > > > Tel: 943 82 17 80 > > > > > > > > > > List info : http://www.activedir.org/mail_list.htm List > > > > > FAQ : http://www.activedir.org/list_faq.htm List archive: > > > > > > > > > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > > > > List info : http://www.activedir.org/mail_list.htm List FAQ : > > > > http://www.activedir.org/list_faq.htm List archive: > > > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > > List info : http://www.activedir.org/mail_list.htm List FAQ : > > > http://www.activedir.org/list_faq.htm List archive: > > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > > > > > List info : http://www.activedir.org/mail_list.htm List FAQ : > > http://www.activedir.org/list_faq.htm List archive: > > http://www.mail-archive.com/activedir%40mail.activedir.org/ > -- > Smith & Wesson - the original point and click interface > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ -- Smith & Wesson - the original point and click interface List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
