Possibly, but I don't see a reason for them to do it really. This, IMO,
isn't an "open source" kind of thing except maybe for some large companies
and I can't see them writing it and then giving it away. 

  joe

 

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Teverovsky
Sent: Saturday, May 29, 2004 12:42 AM
To: [EMAIL PROTECTED]
Subject: RE: [ActiveDir] Anonymous bind

I have went over the Vintela's white paper you posted a link some time ago.
Looks very promising.
But give the Open Source folks some time... go figure, maybe they will come
up with something even better :oP

Guy

On Fri, 2004-05-28 at 01:28, joe wrote:
> Nothing free. :oP
> 
> However Vintela and other companies are working on making this A LOT 
> easier for a price. I expect in another year or so *nix machines will 
> hardly be any more hassle to manage in an Enterprise than Windows
machines.
> 
> I doubt anyone will do something in this arena for free. It isn't 
> exactly the kind of thing the Open Source people really care do to I don't
think.
> More of a corporate thing and I don't visualize any company going 
> through writing this up for themselves and then giving it away.
> 
>   joe
>  
> 
> -----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.o
> > > > > > > > rg
> > > > > > > > /
> > > > > > > >         
> > > > > > > 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/

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