Wish I had a better solution off-hand.  Doesn't sound like you'll get one
that works for you however.  

Al 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky
Sent: Tuesday, May 25, 2004 7:23 PM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Anonymous bind

LDAP with SSL/TLS is way better than NIS.

As for environment, it's two W2K3 forests with Kerberos forest trust.
Forest A has several child domains and holds user accounts.
Forest B is where my hosts are (We are relatively small organization in the
enterprise, but we are R&D and want to have control at least over the
hosts).

So users can come from any child domain of forest A and logon to hosts in
forest B. Now Linux does not play well, when the host is in one realm, and
users are from several other realms... The only workaround is to map uid to
Kerb principal in the LDAP. Modifying the A forest schema (user accounts) is
not an option, and it's quite reasonable considering the small size of our
division.

So here I am, stuck with LDAP authentication ...
If you have any better idea, I am all ears ;)

Guy

On Mon, 2004-05-24 at 16:25, Mulnick, Al wrote:
> Just for curiousity...
> 
> You don't want to use NIS because it's less secure, yet you are going 
> to use LDAP for authentication?  Isn't that a counter?
> 
> Can you give an overview of your topology and what you're wanting to 
> accomplish in the end?  I think we tried to help with the original 
> post without all of the topology information.
> 
> Sounds like an interesting problem though...
>  
> 
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Guy 
> Teverovsky
> Sent: Friday, May 21, 2004 7:01 PM
> To: [EMAIL PROTECTED]
> Subject: RE: [ActiveDir] Anonymous bind
> 
> If you excuse me, I will break the inline pattern ;). It got too
unreadable.
> 
> I have seen the interoperability doc. I have also read the whole doc 
> mentioned in the post. It's a very good reference, but is lacking any 
> description of Kerberos deployments in multi-realm environments.
> Personally I had to choose LDAP authentication instead of Kerberos 
> because my hosts are in one forest, while user accounts are from a 
> child domain of another forest. If someone is aware of a workaround 
> for that, monthly beer supply is on me ;)
> 
> SFU is nice, but it tries to emulate NIS and with all do respect to 
> NIS, it's time is gone. There are just too many security issues with NIS.
> 
> As for having more than one directory, see my reply to joe. I wish I 
> could put it all in one place, but it's not always possible.
> 
> Guy
> 
> On Thu, 2004-05-20 at 03:15, Eric Fleischman wrote:
> > 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.ht
> > ml
> > 
> > 
> > 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;26
> > > > > > > 91
> > > > > > > 90
> > > > > > >  
> > > > > > >  
> > > > > > > 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/

Reply via email to