Hi all, Somebody has tested directory server (http://directory.fedora.redhat.com/wiki/Main_Page) under CentOS 4.1?? Is it ready for production environments?? Somebody has ported to centos?? Thank you very much. __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.espanol.yahoo.com/
> Somebody has tested directory server > (http://directory.fedora.redhat.com/wiki/Main_Page) > under CentOS 4.1?? Is it ready for production > environments?? Somebody has ported to centos??We didn't succeded to compile it from source but the downloadable binaries are working on CentOS. We tested it. The ACI-s and schema are a bit different from OpenLDAP but it's much mature software. OpenLDAP has other advantags - like layers in the betas - but FDS/RHDS/etc. much more usable and stable right now. It needs more resource, off course but it doesn't matter to me. I like stable software much better. bye, Ago
User Lists wrote:> Somebody has tested directory server > (http://directory.fedora.redhat.com/wiki/Main_Page) > under CentOS 4.1?? Is it ready for production > environments?? Somebody has ported to centos??I can't comment about that directory server but I have been using Novell eDirectory on CentOS 3.* without any problems. Considering that it's utilized in numerous universities and government organizations around the world, I would say it's definitely production grade software. http://www.novell.com/documentation/edir87/ http://www.novell.com/products/edirectory/customer_license.htm
Bryan J. Smith <b.j.smith@ieee.org>
2005-Jun-28 17:09 UTC
[CentOS] Directory Server for CentOS 4.1
From: User Lists <clopmz at yahoo.com>> Hi all, > Somebody has tested directory server > (http://directory.fedora.redhat.com/wiki/Main_Page) > under CentOS 4.1?? Is it ready for production > environments?? Somebody has ported to centos??You _do_ understand it's basically Netscape Directory Server, correct? NsDS has been more "production ready" than OpenLDAP ever has IMHO. And yes, it runs on even non-Linux platforms (e.g., Solaris), so I'd say it runs on just about any Linux platform. Integration considerations might be another, more involved detail though. -- Bryan J. Smith mailto:b.j.smith at ieee.org
Bryan J. Smith <b.j.smith@ieee.org>
2005-Jun-28 17:25 UTC
[CentOS] Re: Directory Server for CentOS 4.1
From: Avtar Gill <avtargill at gmail.com>> I can't comment about that directory server but I have been using Novell > eDirectory on CentOS 3.* without any problems. Considering that it's > utilized in numerous universities and government organizations around > the world, I would say it's definitely production grade software.Just know that I've seen NsDS deployed in 10,000+ node networks going back to the late '90s. I don't think people realize what deal the community has gotten thanx to yet another Red Hat purchase released, as always, 100% GPL. OpenLDAP wasn't cutting it IMHO, and Red Hat refuses to offer solutions that aren't GPL. Hence why they came to an arrangement with AOL to see NsDS GPL'd after they "gave up" on OpenLDAP. -- Bryan J. Smith mailto:b.j.smith at ieee.org
On Tue, June 28, 2005 11:37 am, User Lists said:> Hi all, > > Somebody has tested directory server > (http://directory.fedora.redhat.com/wiki/Main_Page) > under CentOS 4.1?? Is it ready for production > environments?? Somebody has ported to centos?? >The plan for Directory Server for CentOS-4 is to port RedHat Directory Server (and not Fedora Directory Server) when it is released for RHEL. That should happen when RedHat thinks it is stable for production in the enterprise ... I would assume that they will charge for it like they do for RHGFS/RHCS when they feel they have it stable. We will release GFS 6.1 for CentOS-4 and RH Directory Services when they release for RHEL. -- Johnny Hughes <http://www.HughesJR.com/>
Bryan J. Smith <b.j.smith@ieee.org>
2005-Jun-28 21:06 UTC
[CentOS] Directory Server for CentOS 4.1
From: alex at milivojevic.org> Hm, sounds interesting alternative to OpenLDAP.Actually, OpenLDAP started as a GPL alternative to NsDS as far as I am concerned. @-p> It says it supports SASL authentication and MD5 password hashes. > Does it also support placing a pointer for SASL where to check the > password into password attribute (instead of placing actual password > in it)?The SASL capability can interface with any GSSAPI solution IIRC. I _know_ that includes a _real_ KDC.> What I'm talking about is putting something like "{SASL}user at REALM" > intopassword attribute. OpenLDAP would than use saslauthd to check > the password(passing it user at REALM and whatever user entered as > password). In my case saslauthd is configured to check passwords > using kerberos5 backend. > Basically, directory server does not store any passwords, passwords > are stored in Kerberos databaseThat's _exactly_ how most enterprise have been running NsDS since the '90s, using Kerberos as the authentication end.> (and I have users spread across several distinctive Kerberos realms > (some Unix based, some Windows AD), to make things even more > interesting).The Florida Institute of Technology created a Windows side service called "acctsync" so a segmented ADS tree could pull/push password and other, basic meta-data changes. This was because more and more ADS-only Windows applications were being implemented, but they still wanted to keep NsDS as their "root" tree (where _all_ users were _always_ created/ removed first). Translation: FIT's AcctSync turned ADS into NsDS' bitch. This was _before_ MS Kerberos was even published, let alone any such interoperability, hence FIT's need and eventual solution. It doesn't use network services and protocols, but is a service that runs on the Windows DCs themselves. The Windows DCs pull/push from/to the NsDS LDAP stores. http://acctsync.sourceforge.net/ [ Side Note: FIT actually didn't use SASL to Kerberos for their password store, but hashes in the directory. But it would have worked for the SASL/Kerberos options too IIRC. ]> (having that functionality is "must-have" for me, before even thinking > about downloading FDS to try it out).Trust me, NsDS has been supporting these details for a _long_ time. Some of it has been with 3rd party software, but others have been BSD, GPL and other projects built around NsDS, even if it wasn't GPL before Red Hat. -- Bryan J. Smith mailto:b.j.smith at ieee.org
Bryan J. Smith <b.j.smith@ieee.org>
2005-Jun-28 21:18 UTC
[CentOS] Directory Server for CentOS 4.1
From: Johnny Hughes <mailing-lists at hughesjr.com>> The plan for Directory Server for CentOS-4 is to port RedHat Directory > Server (and not Fedora Directory Server) when it is released for RHEL. > That should happen when RedHat thinks it is stable for production in the > enterprise ... I would assume that they will charge for it like they do > for RHGFS/RHCS when they feel they have it stable.I thought that have been doing that since the AOL deal last year? It had been available on the RHN for awhile, in the unchanged/original form. Unless I was mistaken, the deal was that AOL would allow Red Hat to GPL it after an undisclosed number of sales had occurred _or_ by April 30, 2005, whichever came first. The new FDS and RHDS releases are just more updated/integrated releases with the Red Hat product line. E.g., more integrated SASL/Kerberos integration with Red Hat's offerings out-of-the-box. Previously there was a lot of post-install work to get Kerberos working via GSSAPI. -- Bryan J. Smith mailto:b.j.smith at ieee.org
Bryan J. Smith <b.j.smith@ieee.org>
2005-Jun-30 19:25 UTC
[CentOS] Directory Server for CentOS 4.1
From: alex at milivojevic.org> As I said, there are multiple domains, so IMAP server can't simply slap > @REALM to the end of user supplied username and do the check directly.Ahhh, a key point I missed. My apologies.> For historical reasons, IMAP server uses flat userspace (while in reality it > is more tree-like). And nope, having users type the @REALM part during > login is not acceptable solution (most of them don't even know what > @REALM should be, nor should they be bothered with such details).Hmmm, most usrs have to do DOMAIN/user for Windows DCs so I don't know how "unacceptable" is is to require "@REALM," but that's just my view. -- Bryan J. Smith mailto:b.j.smith at ieee.org
Bryan J. Smith <b.j.smith@ieee.org>
2005-Jun-30 20:33 UTC
[CentOS] Re: Directory Server for CentOS 4.1
From: alex at milivojevic.org> Nope. On Windows during login users usually selects domain part from > drop-down box (yes, you can type it too if you want).[ Not that this matters, but ... ] First off, that's _only_ for the GINA portion, and not always. Unless you take the time to distribute all domains either at the server or client, you won't always see all domains. Secondly, inside of various apps, credentials are not always passed correctly, which requires the nomenclature. Of course, the application can save the username and other settings in the application itself. E.g., try to login to IIS' FTP server when you have multiple domains. ;-> You'll have to pass the DOMAIN/user nomenclature in many cases.> And usually whatever domain is selected in that drop-down box by > default is the correct one for the owner of the particular PC.[ Again, not that it matters, but ... ] And the same can be said for applications on a UNIX system with a particular user's login, and their configuration files (and mounted home directory -- you are automounting home directories, yes?). I'm kinda scratching my head here. I can setup a user's IMAP credentials in various applications (both Windows and UNIX/Linux) to remember their username for the setup, so that is avoided. I don't see the difference between multiple REALMs and multiple NTDOM/ADSDOMs. If you properly configure the login/apps to remember the user's domain, then it's not an issue.> Anyhow, historically real Unix accounts were used on email servers, > so after switch to virtual accounts requirement was that users don't > notice the change. Higher authority decided that it would be too > complicated for non-technical population to swtich from "username" > to "username at REALM".[ Lastly, also mot that it matters, but ... ] What are you using multiple REALMs for anyway if everyone was under a "real UNIX" account before? NOW WHAT MATTERS ... _Please_ read up on how NsDS works. It's _extremely_ "enterprise class" and much more capable than OpenLDAP, which was more of an "open framework" of different capabilities (not always well integrated). http://www.redhat.com/docs/manuals/dir-server/ag/ssl.htm "Netscape Directory Server Administrators Guide Chapter 11 ... Configuring Kerberos Kerberos v5 must be deployed on your system to utilize the GSS-API mechanism for SASL authentication ... ... Realms A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms. Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP URL: uid=<user_name/[server_instance]>,cn=realm,cn=mechanism,cn=auth " Is that more of what you were looking for? How to put the Realm in the uid? -- Bryan J. Smith mailto:b.j.smith at ieee.org
Bryan J. Smith <b.j.smith@ieee.org>
2005-Jun-30 21:42 UTC
[CentOS] Re: Directory Server for CentOS 4.1
From: alex at milivojevic.org> I'm abusing the fact that all users have accounts on one of AD domains.Ahhh, so let me get this straight ... Your users are virtual, yet they have real accounts in ADS? Is this just for LAN? Or are you an ISP/ASP?> The "Unix" services are not aware of it. They simply authenticate user > against flat userspace on LDAP server, and the LDAP/saslauthd component > is smart enough to contact appropriate AD domain.Ahhh, a very interesting setup indeed. Are you using ADS because the users are normally logging into Windows? [ And this is a LAN setup, not an ISP/ASP? ]> So, no I'm not using Kerberos as such, because in reallity the clients > users have can't use it either (reason is simple, most Windows software > don't talk neither Kerberos nor SASL - they are all username/password > based with option to pass it over SSL/TLS).Actually, that's not true. You can replaced NT's GINA with pGINA (pluggable GINA) and authenticate and setup your credentials against various authentication/directory services. Unless, of course, you are using software that absolutely requires ADS.> I'm simply abusing the fact I can authenticate against AD domain > using Kerberos as protocol.Correct. Again, I'm curious if this is because you already use ADS for other purposes? Or someone decided that ADS was "easier" to support?> So the question is. If I have user-a and user-b, where user-a exists > as principal user-1 at domain-1, and user-b exists as principal user-2 > @domain-2, can I have FDS authenticate the user against appropriate > domain if passed only the "id=user-a,dc=mydomain,dc=com" or > "id=user-b,dc=mydomain,dc=com"? No SASL, no Kerberos mumbo- > jumbo all the way from the user's client software to LDAP server > (what happens between LDAP server onwards can be anything, as > long as it works).It seems so based on the page I sent you. Although I think you might have to change your string slightly. The docs explicitly stated that 1 server _can_ authenticate against _multiple_ realms. I don't see how your setup is different, except for using the MS-Kerberos protocol which has been integrated into newer Kerberos client implementations. -- Bryan J. Smith mailto:b.j.smith at ieee.org