LOL. This week I had a chat with a guy from Novell. And as I do not know much about NDS, but have some clue about AD, I was interested in the differences between both directories. The ability to split partitions and the replication traffic were among the things he mentioned. And my reply was the same: with todays infrastructure the overhead is minor.
Guy On Thu, 2004-05-20 at 18:06, Eric Fleischman wrote: > There's no question that this is a sliding rule. And I think somewhere else down in > that post I noted that but am not seeing it right there. > The bottom line is that there will always be a cost/benefit to putting a piece of > data in a replicate location which spreads out to other servers where it might not > be required. That comes at the price of cost though.....it's a trade off is all I'm > saying. > > In this case, given the size of what we're talking about (megabytes?) it probably > isn't the end of the world. And it won't change often either. > > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe > Sent: Thursday, May 20, 2004 9:57 AM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Anonymous bind > > > [EFLEIS] - So we think it is easier to sync over a subset of > > data to the other directory, extend there and populate there? > > Rather than just putting it all in the main directory? I'm > > sorry, I just disagree. :) > > Hmm I have mixed feelings on this one and would say... It depends. I can see > cases to put the data in the main directory and cases to have it someplace > else. Especially as your directory gets larger and larger and has to get > replicated out to the four corners of the universe to DCs sitting on the bad > side of very nasty telcom lines. This goes for any data in the direction, > not specifically this conversation at hand. I think the larger and more > distributed the directory the more you should consider only putting in data > that is needed in most of the locations that the directory exists. For > instance... Say Exchange. :o) If you have a Data Center centralized > deployment of Exchange and a WAN distributed deployment of AD no reason to > shoot the Exchange Data all over the place. > > Basically the smaller the deployment the better chance AD should be the one > stop shopping place. > > joe > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman > Sent: Wednesday, May 19, 2004 8:16 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Anonymous bind > > A few bits more..... > > [Guy] I know that I am speculating here but all I wanted to do is to point > the finger to the interoperability issue. Setting up a heterogeneous > environment is a pain. Putting *nix clients (or services) into the AD mix is > not easy. One would blame the marketing attitude, the other would blame the > maturity level of the other OSes. The truth, I believe, is somewhere in > between. So here we go: > > [EFLEIS] - Have you seen the whole paper we wrote on Kerb interop? And just > about anything around SFU (which might I point out again won best app at > Linux world)? I think we've done a great job of interop. Can we do better? > Always! And we continue to work on it. But we're doing a *lot* in this > space. > We have doc's out there that go down to even walk you through how to set up > the pam modules! We have a lot out there. Here's one of my fav docs, but > there are others....this is from a post to this very DL: > http://www.mail-archive.com/[EMAIL PROTECTED]/msg13880.html > > > 1) You are right. Nobody mentioned schema extensions, but the truth is that > if you are considering the integration of open source services, you probably > do have some Linux boxes around. NIS sucks big time. NIS+ is a pain to > configure and both do not give you SSO. AD is great, but does not have > out-of-the-box capabilities to absorb non-MS clients. So what is left for > those that can not afford VAS ? Either tweak the schema (Linux client will > have hard time without posixAccount and posixGroup > objectClasses) or have a cut down functionality (sendmail LDAP mail routing > is great, but I would not extend the AD's schema just to make sendmail > happy). And if you are still short on the $$$, you are starting to improvise > (talking about OpenLDAP...). SMBs are somewhat neglected in this area. > > 2) Small *heterogeneous* environments. If all you have is Windows, there is > no reason to bring in more overhead. Long live and prosper AD ! > > 3) > a) Linux clients logons require uid, uidNumber, gidNumber and etc... > (SFU sounds nice at first, till you hit the non-RFC compliance barrier of > uid attribute in SFU and realize that NIS is by no means not a secure > environment) > [EFLEIS] - Yup, SFU can do this. Schema extension required of course, but > painless (if memory serves me correctly, no PAS extensions there). > > b) a lot of *nix services can be easily managed through LDAP > backend, though the interoperability issues with AD force the creation of > another directory. I totally agree with you here - it IS overhead, but if I > extend the schema with app-specific *nix extensions I put myself in danger > of that specific extension colliding with future (no offense) MS insights :) > and I do not want mangled attributes in AD. > > [EFLEIS] - So we think it is easier to sync over a subset of data to the > other directory, extend there and populate there? Rather than just putting > it all in the main directory? I'm sorry, I just disagree. :) > > c) I am writing these lines right after bachelor's party of one of > my friends, so my apologies for not coming up with more. Promise to be back > to my senses tomorrow. > > [EFLEIS] - Hehe, I can't help you here. :) > > > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky > Sent: Wednesday, May 19, 2004 7:01 PM > To: [EMAIL PROTECTED] > Subject: RE: [ActiveDir] Anonymous bind > > Inline is fine by me ;) > > Cheers, > Guy > > [snip] > > [EFLEIS] - So you don't like anonymous access on AD because it is hard? > It's two steps....one to allow the bind, one to give access to the > resources. It's like a light switch + a dimmer. Turn it on, then tell me how > much you want. Click in, then turn the knob. I actually like it this > way....now you can wholesale turn the whole thing off with one flip of a > flag in dsHeuristics and not have to touch your ACLs until later when you > see fit to do so. > > Or is there more to what you're trying to say here that I'm missing? > [Guy] As I have already said, this is something I was not aware of. > Thanks for pointing that out. > btw, KB 326690 still mentions 7th bit. > > [snip] > > [EFLEIS] - Wow, many corrections to be made here: > > 1) I don't recall seeing any mention in this thread of a schema extension, > only change in ACLs to facilitate a client. There's been no discussion here > about schema extensions, but if I'm missing the point where there was please > point it out ot me. > > 2) What I found interesting is that you said you like this for small > enterprises and a single directory for large. Many customers would argue > that the ideal is the other way around, since the small shop has fewer > resources to invest in settting up and maintaining the sync mechanisms. > While I wish everyone had a single directory, if forced to pick a group of > people to sync, I'd rather it be the big guys than the little ones. > > 3) You said many advantages, but only cited: > > a) same OpenLDAP for Linux client logs - same as what? I'm not sure > I follow. It sounds like the Linux client config would be the same. > > Where are the others I missed? > [Guy] I know that I am speculating here but all I wanted to do is to point > the finger to the interoperability issue. Setting up a heterogeneous > environment is a pain. Putting *nix clients (or services) into the AD mix is > not easy. One would blame the marketing attitude, the other would blame the > maturity level of the other OSes. The truth, I believe, is somewhere in > between. So here we go: > 1) You are right. Nobody mentioned schema extensions, but the truth is that > if you are considering the integration of open source services, you probably > do have some Linux boxes around. NIS sucks big time. NIS+ is a pain to > configure and both do not give you SSO. AD is great, but does not have > out-of-the-box capabilities to absorb non-MS clients. So what is left for > those that can not afford VAS ? Either tweak the schema (Linux client will > have hard time without posixAccount and posixGroup > objectClasses) or have a cut down functionality (sendmail LDAP mail routing > is great, but I would not extend the AD's schema just to make sendmail > happy). And if you are still short on the $$$, you are starting to improvise > (talking about OpenLDAP...). SMBs are somewhat neglected in this area. > > 2) Small *heterogeneous* environments. If all you have is Windows, there is > no reason to bring in more overhead. Long live and prosper AD ! > > 3) > a) Linux clients logons require uid, uidNumber, gidNumber and etc... > (SFU sounds nice at first, till you hit the non-RFC compliance barrier of > uid attribute in SFU and realize that NIS is by no means not a secure > environment) > b) a lot of *nix services can be easily managed through LDAP > backend, though the interoperability issues with AD force the creation of > another directory. I totally agree with you here - it IS overhead, but if I > extend the schema with app-specific *nix extensions I put myself in danger > of that specific extension colliding with future (no offense) MS insights :) > and I do not want mangled attributes in AD. > c) I am writing these lines right after bachelor's party of one of > my friends, so my apologies for not coming up with more. Promise to be back > to my senses tomorrow. > > > > > > > > > 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/ > > 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/
