Slashdot Mirror
Directory Service Implementation From Scratch?
An anonymous reader writes "I work at a small but growing startup company. Currently, our directory and authentication information is scattered across many systems and wikis, and is becoming increasingly difficult to manage. We are looking at centralizing this information in a directory service to minimize administrative overhead as we continue to grow. The service must support basic directory searches, as well as user authentication for Linux and Windows hosts. Although we are primarily a Linux shop, there are a handful of Windows systems that will be on a Windows Active Directory domain. Most directory servers seem to support integration with other directory servers, however it seems like it may be easiest to just use Active Directory for everything. Are there any pitfalls with this approach? If you had the chance to redesign your enterprise directory service without regard for legacy services, how would you do it?"
Use AD.
Even though folks will fuss and whine about AD being not pure LDAP, for all intents and purposes it is, and we've got lots of Linux and other *nix boxes using it for authentication. And remember, you can always extend AD for your custom applications easy enough. It's simple enough that MCSEs can run it.
Depending on your company's skillset, having AD as your core directory may be your best choice. The advantage is that its one point of access, one set of usernames and passwords for users, and so on.
AD in general also has a lot of management tools and knowledge available.
Of course, this isn't to say that OpenLDAP or other directory solutions are bad. Its just that in general, most vendors will bend over backwards to give Active Directory support for their products.
i took a class once where we used LDAP (Lightweight Directory Access Protocol) and then used Ubuntu and VMware to setup multiple Ubuntu/Win2k/WinServer2k3 all with roaming profiles and active directories.
it worked great and was a really fun class also.
I really hate to say it, but I think Active Directory is most definitely the way to go. No other directory systems allows for as simple administration of a large number of windows computers, your windows clients will "Just Work" with it, and it isn't difficult to make windows boxes, wikis, etc authenticate against it (I've had to do this many times...).
Active directory lets you access it via LDAP which a lot of software packages understand (a note here, structure the LDAP binds such that the username is in the form of SAMACCOUNTNAME@WINDOWSDOMAINFQDN, this has worked almost every time for me).
The free version of Likewise Open will make it very easy for the linux boxes themselves to authenticate against AD without having to mess with any pam conf yourself, and if you pay them money you can even deploy GP's to linux boxes (disclaimer, I've never tried this part).
In sum, while I hate to say it, you can make almost any client solution work with AD either directly or via LDAP or Kerberos, and it's the best possible solution for windows client management, so I'd go with that.
Just my .02
use Novell's eDirectory, it may cost, but they have a product called "Identity Manager" which allows you to interconnect many different systems to a central ID vault. Password changes are transparent, and management is extremely easy. Best of all it runs on Linux. You don't need the "netware" component to use it. It scales like a dream and is very robust
~corporate tool, but employed~
quit your job and let someone else deal with it
1.) RHDS - Red Hat Directory Server
2.) Active Directory
3.) OpenLDAP
4.) Novell eDirectory (personally my least favorite)
I would probably jump for RHDS first, then AD. The only problem with OpenLDAP might be getting a similar level of support to the first two. Support is exactly why I would never choose eDirectory. I have (personally) had abysmal experiences dealing with Novell. Others may disagree though. And of course there probably are other options.
Almost any LDAP Directory service will work for your directory needs. I think the real question should be "is the cost of the Windows Server 2008+CALs outweighed by the extra features I get?". If you're considering Active Directory then you should know that as a bare minimum you will need two Windows Servers. But you will get GPOs, centralized security (domain users and groups) etc. Do you need all that? If you're a startup then spend money on getting your business up and running, not on keeping Ballmer's office stocked with chairs. So stick with any of the worthy Linux-based. FOSS solutions - I have limited experience with them so I'll leave others to comment on which is "best". (Disclaimer: I deployed AD to my company - they're a 10,000 employee global company that was running Windows NT everywhere when I joined.)
Wow.. did I wake up in another dimension? Are slashdotters actually recommending MS products today??
Microsoft has really done well with developing AD.
It's just honestly the best product out there currently.
aka fedora-ds has been very flexible and is able to provide SSO for many applications, from apps that support pam, to tacacs, apache, cvs etc. admittedly i havent gone so far as to auth a windows pc against it, but that doesnt mean it's necessarily a good idea to use AD and have linux auth against that. multi-master replication in 389 works great, and we even have a 3rd master who is on the other side of a wan-link.
You can configure a Samba server against LDAP and have everything authenticate agaist that. Your biggest pitfall is going to be finding support for the configuration. You have to consider "what if the IT Admin get's hit by a bus, who's going to support this configuration". With Active Directory you can flip open a phonebook and find a dozen local places that will support it; that's not the case with the Samba/LDAP configuration.
FreeBSD.org - The power to serve
Umm... AD uses LDAP....
http://www.freeipa.org/
Ad is very nice, we use it for Auth in a mixed env as well. I work in QA, the way that I've actually got mine setup is ADS run by Corp, FDS run by QA. FDS has Pass Though Authentication turned on.
You may want to checkout Fedora Directory Server and FreeIPA combo for linux/unix solutions
you have zero enterprise experience
Yes, SQL. If you keep your raw data in SQL, it is easy to export data to any format you might need now or in the future. LDAP gets you a long way, but you will sooner or later end up with several apps that don't support it. The result is horrible password sync hacks, multiple passwords per user, etc.
The idea is to put raw user info in SQL, including their clear-text password. Of course, lock down that SQL server like you've never locked down anything before! It should have a very limited interface for updating user data. Next, export user data to relevant external databases such as LDAP, NIS, SASL, that obscure sqlite app, Kerberos, DMZ services, etc, and you'll have much less pain keeping everything in sync.
An implementation of this scheme is running on many of the biggest universities in Norway, and is called Cerebrum, http://www.cerebrum.usit.uio.no/english.html. User administration happens through a frontend interface appropriately named BOFH, where users and admins can change data in a secure manner. Users can change certain of their own attributes, while admins have more power. It's worth checking out (although their sf.net wiki seems to be down at the moment, unfortunately).
I'd use AD for everything. It works out of the box. Isn't that expensive. Does replication properly. Tracks site locality. Is expandable instantly to huge networks. Has Kerberos set up perfectly by default. There's really no downside to using it in my experience. All of hte other solutions require massive hand holding. Linux can auth against it either as a normal LDAP directory, or using Winbind. Winbind recommended.
Is it really necessary to have 6 smilie faces in the article? I wonder how many also show up in the Drizzle source. I also find it interesting that the author opts for the less common "no-nose smilie face" :)
Windows 2003 R2 has (virutally) the same IDMU as Win 2008.
I have implemented such a mixed environment, with one problem. As I pointed more and more liunx boxes at the AD running IDMU, the number of internal connections from the AD server to it's own LDAP port increased until they were all tied up. It got so the AD server could not even read its own global policies.
I had to implement a Linux NIS slave and point all of my Linux boxes at it instead of the AD server.
Depending on your size you might want to consider Apple's OS X server product.
I am in the middle of building a new infrastructure based on open directory which is apple's version of LDAP. so far I have the mac, linux and windows boxes authenticating against it, as well as postsql, drupal,
still working on fully setting it up, but so far so good.
It's replacing:
netscape old LDAP
Sun's NIS+
Redhat NIS
and Active directory
so in the long run it should be better than what we have now
Novel sells Zen, which does an LDAP domain like AD, hosted from Linux. Yes there might be incompatibilities with Windows, but Windows typically has incompatibilities with Windows too. Novel's stuff will probably support your UNIX systems better. The admins I've met running Novel seemed happy with it, especially with the security features and invulnerability (low incidence) to typical internet malware.
Also, you are missing the point of LDAP and AD. LDAP directory services can TALK TO EACH OTHER. It's based on standards. You can have a Linux-based LDAP forest talk to a Windows-based AD forest. It will work. There may/will be problems, but consider this:
most of the time, your linux servers will deal with the linux LDAP server
most of the time, your windows servers will deal with the windows domain
file & data transfers can also be done a variety of ways that don't involve directory services. SSH with private key auth. The HTTP your using now is another.
If system administration is becoming a burden, you just need to automate more. Write more scripts. Work as a team to automate most tasks until you have less and less to do. A perfect, orderly domain doesn't exist and may cause more problems than it solves. Cron/scheduler that downloads new/updated scripts from a central server can solve a lot of these issues without all the overhead and licensing, especially if you have special vendor application that can't run in a domain (the vendor won't support it).
Its going to sound like blasphemy here on slashdot, but I strongly recommend one master ActiveDirectory server with Services for Unix installed. You can manage everything from the nice pretty windows GUI, have perfect windows support and using pam_krb5 and nss_ldap (I use them in FreeBSD, I believe both of which were originally for linux, not sure they would be the best for it) for pulling all your user information from AD. Services for UNIX adds tabs to the important objects in the ActiveDirectory UI to let you edit the unix attributes.
Combine nss_ldap, pam_krb5, sasl with kerberose auth, and samba 3 or newer, the kerberos auth module for Apache and you can have complete and total authentication based on ActiveDirectory with a very nice GUI, and you can still use standard ldap tools to work with the directory if you want. Samba will do kerberos with windows beautifully at this point, just make sure you keep eveything time synced. Even does all the 'single signon' stuff for websites.
You end up using a great authentication mechanism on your unix AND windows hosts (kerberos is king). The only catch that may or may not apply to other OSes, but it definately bit me in FreeBSD 6, FBSD wants to use UDP for all its kerberos communications which is normally fine, but once you get a user with a large collection of kerberos data, in my case, lots of groups either directly or via nesting, then the packets become too large for a single UDP datagram and FBSD is too stupid to switch to TCP on its on. My solution was simply to block all UDP port 88 requests in and out of my FBSD boxes so they immediately fail over to TCP (not, you have to return ICMP errors, not just drop packets or it'll just hang as it doesn't know the packet can't be sent).
Not sure if Linux's kerberos implementation supports forcing TCP in krb5.conf. FreeBSD is SUPPOSED to, but older version certainly don't.
I know that no one likes MS and thinks they are evil, but I've been VERY happy using AD. We have two Win2k3 machines that serves ActiveDirectory, basically a primary and backup domain controller in the old MS NTDOMAIN language. Works awesome. If you throw in the MS certificate server on your AD server, then you also have a nice way to make internal SSL certificates with full revokation support and all that neat stuff so you can make internal certs all day long and the since your Windows machines are part of the ActiveDirectory, it pushes its root cert to all your windows boxes meaning you don't have to do crap to make them fully authenticated certs for your windows machines.
With far less effort than any other directory server you can have full single sign on support, good authentication, and an easy to use interface in which you can delegate control to various folks outside your IT department and let them use the AD manager for windows (on xp or whatever) to manage the department they need to if you want. You can auth pretty much EVERY modern OS this way. Hell if you want to you can run the servers on Unix (OpenLDAP/MIT Kerberos) for backup or for serving client requests and just isolate the windows machine as the master if you want.
Okay, now I sound like a total fanboy, please don't hate, but it really is a good setup. The main reason being, from my point of view, the setup and most importantly, the administration of ActiveDirectory and Services for UNIX are FAR above and beyond anything the F/OSS world offers. Sad, but true. I imagine you could probably get good support from Novell eDirectory as its tools are pretty good when they work, haven't used them since 6.0 when all their Java apps were asstastic, but I was only admining the leaf node of a tree with a few hundred thousand accounts in it (State of Georgia was using eDirectory a few years back, all their employees are in it, may have changed by now), so it may work better in smaller setups. All things considered it didn't do bad there, was just far too slow for editing my own subtree as we had to wait on updates to be pushed back up the tree bef
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
There are times to show off to the world how much of a geek you really are, but this is not one of them - why reinvent the wheel? Just use AD. It works.
I am with this task as well.
Since we need to support Kerberos, I had some difficulties to install OpenLDAP and manage the Kerberos and integrate with Samba and AFP.
Our servers are 80% Linux and 20% Windows,.
Our clients are 90% Mac, 9% Windows and 1% Linuxes
I have messing with the follwoing solutions without much sucesse. They are all good, but they are NOT READY yet. Maybe Novell eDirectory, but I think it is too big and kind of expensive.
I really don't like Microsoft, so we are avoiding AD and avoiding supporting M$ with our money.
So, we tried:
- Fedora Directory Server
- OpenLDAP + Kerberos (doesn't have a good admin interface)
- Gosa
- FreeIPA
But, we will keep investigating.
for now, our BEST OPTION and the easiest is:
Apple OD (Open Directory).
It integrate very well with Windows, Apple, Linux and has Kerberois and a great Admin UI
Ou ONLY problem with Apple is that we can't VMWare... so, that's the only issue for us!!!
In about 6 months we will try again the followings:
- FreeIPA
- Gosa2
- Fedora Directory Server
Everyone hating on MS but loving AD. Sweet sweet irony.
The Linux/Unix world has done a great job making AD work in their world. Just like we can read mail off an Exchange server and use Sharepoint. They are easy on day one, but like most products from MS, there are a million hidden costs as you grow and expand. If you start with a standards based LDAP directory server like 389-ds (Fedora-ds new name) you can grow into RHDS if you need support. It is cheaper than AD as your environment grows plus if you decide to migrate to another DS, it is reasonably easy because it implemented an open standard. Don't fall into the trap like so many did with Exchange and so many are with Sharepoint.
First off, AD does provide LDAP services, it is ActiveDIRECTORY after all.
Second, every OSS app out there pretty much lets you modify the schema it expects from the server, meaning making it talk to an ActiveDirectory server is just a matter of properly setting up the schema. Hell most apps now days already have an example config for talking to a stock ActiveDirectory, but you're better off with AD + Services for Unix so you get AD and Unix UID/GID administration in one pretty point and clicky interface.
Other than having a more flexible schema, since it doesn't assume you need to talk to windows, its inferior to AD in just about every other way, excluding price, where of course it beats the shit out of AD :)
If your last two startups were made easier by not using AD, you have incompetent admins who don't actually understand ldap or kerberos.
With openldap you get a directory, which CAN be used to authenticate, but thats not what you should be doing. Kerberos is accepted everywhere as the best authentication system to use in an organization, hands down, Unix OR windows. With AD you get both. Which means instead of using your crappy 'bind to auth' or 'bind as someone then query to auth' and 'hopefully we remembered to use SSL everywhere that needs auth', with AD you get LDAP + kerberos for auth, best of both worlds.
AD allows you to manage users with those same applications, host or web based as it support LDAP perfectly so OpenLDAP doesn't have anything on it there.
Fourth, you can just make samba join your activedirectory server instead of making it pretend to be one and dealing with all the quirks that goes with that if you have anything beyond the most simple of setups.
Want samba to join ads? Install samba 3 or newer, install a time sync utility if you don't already have one, type:
net ads join
Follow prompts, done.
Go the next step and tell samba to generate a keytab for kerberos for you and be happy as now you can start using kerberos for other services rather a cobbled together bunch of hacks to bindauth or queryauth off the ldap server.
Me thinks you don't really have any actual experience with or an idea what AD is. AD is NOT NTDOMAINS, even though an AD server is capable of providing backwards compatibility, it is not required and if you're using not using anything older than XP and unix machines it should be turned off.
OpenLDAP is only a partial replacement for ActiveDirectory, and really is the WRONG way to do authentication. MS didn't invent kerberos, but switching to it was one of those 'Okay, you win, we're on the bandwagon with your protocols' moments that you should actually thank them for and look into. Stop hating and educate yourself.
What OpenLDAP wins at, hands down, is of course, cost. But its really silly to say that its more flexible or more reliable (which, btw availability and uptime mean the same thing here).
Do you want to use a bunch of hacks to make your windows machines authenticate, or would you rather use a system that supports everyone natively and completely, Windows AND Unix (including OSX)? Personally I went with AD so I can just do everything natively, with Services for UNIX the thing will even function as a NIS (maybe NIS+, I don't use that part) server if you've got old boxes that you need to pull into the group.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
If you want to use kerberos you'll need to avoid Active Directory -- it does not play well with others. AD is a decent directory server, but the "kerberos" implementation muxes authorization and authentication and will not work with external kerberos servers at all.
On the other hand, AD does play very well with Windows desktops -- it is the only way to use certain administrative functions in Windows -- and is perfectly suitable for password-based authentication against the directory sever from any platform. So if you don't need kerberos AD is probably fine, though I'm not sure it's any better than RHDS or eDirectory or the like if all you're doing is centralized, password-based authentication.
It's just another dimension of Microsoft's brokenware mentality. They design a product, then they break it before selling it to you so they can sell you an upgrade to a working version. CALs are the server equivalent to the PC/workstation scenario. They don't provide different versions of Windows with different capabilities. They do provide different versions of windows intentionally broken to different degrees. They're creating an artificial feature set that they can up-sell later.
It's diabolical, really, but it's hard to blame them. They are a business very near (or at) monopoly status trying to eke every last penny out of our pockets. What more should we expect?
I won't join Slashcott. OTOH, If Beta goes live, I just won't be back until it's fixed. Sorry Dice.
There is also:
Apache Directory
Sun OpenDS
Winter 2010: With Glowing Hearts
Or there's something like symplified, they have a single sign on software that's made specifically for this sort of purpose. It's not F/OSS though, so keep that in mind too, but I looked into it recently and it seemed pretty nice.
" it seems like it may be easiest to just use Active Directory for everything. Are there any pitfalls with this approach? "
No no no.
Go do samba+ldap and THEN you have BOTH windows and a linux directory. You might hear something about "group policies" and other crap, thats treated in-depth in the samba howto: you CAN deploy policies with a smb pdc to winxp-2k boxes without too much problem (youll need a cheap version of win2k and ads with minal cals to get the admin gui for that, but in no way should you pay CALs for your linux boxes: that is plain stupid).
NO SIG
In a high availability situation I would never trust AD to work with my nix machines. All it takes is Microsoft to make one change in the code and an admin to apply a patch to the AD servers and your nix machines can all be sitting their twittling their thumbs. Then you are stuck hoping that Microsoft wants to fix the problem. Mean while management will be sitting their blaming your nix machines and thinking it is better to go all windows. If your shop wants to go all windows do it based on a buisness requirement not based on getting bent by microsoft yet again.
I have felt your pain. I just got my used copy of Distributed Services with OpenAFS: for Enterprise and Education and it looks pretty awesome so far.
It's a textbook of explanations wrapped around a whole bunch of script(1) captures of them setting up ntp,dns,k5,ldap,openafs,samba, etc on Debian with Windows, Mac, Ubuntu clients. You can find the table of contents and an excerpt at the book's site: http://www.springer.com/computer/programming/book/978-3-540-36633-1
hth and Good Luck!
adric
<script>alert("I never liked JavaScript, really; it just seemed a bad idea.");</script>
If you're a Linux shop then either stay away from AD or throw Linux away. AD is far from the best directory server, the value in AD comes in the non-directory aspects tying it into other Microsoft products. If you're a Linux shop, then deploy a good directory service (e.g. FDS, OpenIPA, eDirectory) an tie the handful of Windows boxes into that infrastructure.
Yikes, I'm replying to an AC.
Mac OS X and Server are now virtualizable in recent Vmware Fusion and Parallels installs (at least). Although there were technical and legal challenges to parallelizing OS X installs, these have apparently been surmounted.
Now I just need more RAM.
<script>alert("I never liked JavaScript, really; it just seemed a bad idea.");</script>
I find myself in the same situation and am considering either MDS or FDS, which is now 389 Directory Server btw, to address this need. My goal is to stay away from Microsoft's AD primarily because my boss looks for $100 solutions for $10 (or less). I won't banter on here about the merits of what MDS will and will not do, but I will say it's a very good package, well documented and certainly worth consideration. I setup a VMware server which I'd be happy to ZIP up and post on our company's sftp site for you to download and check out if you so wish. Look me up and I'll hook you up, no worries...
seriously... this is a freakin' M$ love-in...
since when has "simple", "gui" and "proprietory" been pre-requisits on slashdot?
AD is far from the best tool for the job for hetrogenous computing environments. it has limitations in the number of entities it can hold, it's buggier than a swamp and the granularity of security imnsfho, crap. if you decide to get on the AD train, don't forget to purchase ADAM as the recomended and part-of-the-solution-set to get anything to play nice that isn't winblows.
if, like me, you like to put in place solid, stable, secure and infinitely configurable systems and infrastructure, but *nix is all scary, try putting "howto" in front of you google search, here's what I found, and it works. just works. keeps working.
http://www.kernel-panic.it/openbsd/pdc/
if you're setting this up for a dev shop, the code monkey's will love you when finally a suit comes around dropping jargon like "single sign-on" - they can code against technology that doesn't cost an arm and a leg, is completely documented and adheres to "standards" - those are the things M$ never attain.
anyhoo, enjoy the infrastructure building, just remember - if a tarded microserf can't do it with one click, then the tarded microserf can't f##k it up.
I'd rate your best option, by far, is eDirectory
Fully LDAP Compliant.
Can handle your directory regardless of how large it gets (AD STILL has scaling issues)
Can remap all the default mappings for both attributes and classes so you could very easily have your eDirectory tree replicate the behaviour of everything from AD-LDAP to OpenLDAP
Latest eDirectory services on OES 2 SP1 include Domain Services for Windows, allowing *native* AD calls to work (you can even manage your eDirectory with MMC)
And if you ever find eDirectory can't do everything you want it to, you can always use Identity Manger to sync your eDirectory to practically any other service you're using.
Sure, AD is great, if you're a total Microsoft house, but you'll have nothing but issues trying to get it to play nice with your Linux kit, and if you get yourself near 15,000 users you'll be wishing you had a system that scaled.
OpenLDAP is great, if you're a total non-Microsoft house, but you'll have nothing but issues trying to get it to play nice with your MS kit, and if you might find some of its feature set limiting.
You can use too:
Apache Directory (http://directory.apache.org/)
Sun OpenDS (http://www.opends.org/)
today I have a job implementing a single sign-on solution to be integrated with system stuff of company, internally using OpenLDAP. But in my development process I am using Apache Directory as development platform to do this job at all and I see as good solution many because the manager application (Apache Directory Studio).
With the mostly Linux/UNIX boxes and only few Windows boxes Apple's OS X Servers Open Directory (openLDAP/Kerberos) is very easy to use, and with less than 8 clicks you can have SAMBA configured with it to authenticate the Windows boxes. All clients would use Kerberos for authentication, plus you are using open source technology.
Depends on what control you want over the Windows boxes.
Linux/Mac/Windows Admin
I notice that whenever someone recommends sticking with Active Directory, they apologies for recommending it.
It's amusing because they're apologizing for recommending the best solution in this situation, which is EXACTLY what a good commenter should do. They have nothing to apologize for, and so I guess their apologies are more for the fanboys than anyone else who cares about a good result.
Just admit it - OSS doesn't always work, so making a suggestion which involves using Microsoft technologies is nothing to be ashamed of. It shows you aren't an idiot and prefer the best solution as opposed to a Slashdot friendly solution.
I replaced an AD domain with Samba/OpenLDAP, in a mid-sized enterprise of 13 networks nationwide (~30 windows boxes each), it works like clockwork. AD works allright, but until there's a Linux version of it, you'll be enslaved to the whole Microsoft administration nightmare experience: restart-every-x-weeks/update-patch/virus-proneness etc. including the MS tax of course, wich includes call-licenses (one per client)...
OpenLDAP Pros:
Robustness: it's a snap to set up replicas everywhere.
Efficient: faster in the same hardware than a win2003/AD, the bandwidth and time needed for replication is nothing compared to what AD needs, also you don't need a cluster to make it robust, it just is.
Simple to set up if you are using the packaged version (I've used Ubuntu's and Debian's versions, they work out of the box), although for specific customization/needs it may not be as simple as clicking NEXT until your index finger is sore.
Flexible: you can authenticate almost anything against it, there are decent LDAP libraries for most programming languages, and you can pick your choice middleman authenticator: Samba, PAM, Radius, or even POP3, to name a few.
Secure: if you have your own x509 PKI (and you should), it's easy to have everything working under SSL.
Good documentation and support: there's already a ton of how-tos and tutorials on how to get it working and there's always the mailing lists and forums.
Easy to troubleshoot: just increase the verbosity of log/debug levels and you can figure out exactly what you've missed.
Easy to back up and recover: back up your database to a plaintext ldif file and recover/create new replicas in a blink.
Oh, and it's Free software.
Cons:
It's not AD, so AD magical stuff for winXP/Vista is not there yet, but wait for the next version of samba and you'll get some of it if you really need it.
You need to read a little and actually understand what you are doing to set it up, but the time you spend learning how to setup OpenLDAP is but a fraction of the time you'll spend actually managing an AD network.
OpenLDAP has really simplified things around, users have a single account for: windows domain, squid proxy, apache, jabber, email, webapps etc. And it also holds postfix's virtual aliases and squid's ACLs. Everything in a single replicated, secure 'place'.
I have a pretty long history of this, and I have set up a couple of major implementations (1,000,000+ objects) so I'm putting in my 2cents.
I started with Novell's NDS in 1993 (yup, I was a beta tester) and so I am pretty oriented towards that product. Other Directory Service products I have managed include AD and eTrust. I am still most impressed with Novell's product, and for good reasons. AD is really an LDAP interface into a distributed registry. It is not really a full X.500 directory, and it weaknesses show when it comes time to upgrade or migrate. eTrust is built on the old Ingres database (Alan Lloyd couldn't get a free copy of Oracle) and there were issues with it's replication and failover modes when I ran it. Once burned, twice shy. The most reliable, in terms of not getting up at 2 AM, was eDirectory, and I still respect Novell's attitude towards Quality.
The performance of most DS products is pretty equal these days, a test I read last year had a 4-core Opteron doing 60,000+ searches per second. That's plenty, divide the number of leaf objects by that number to find the number of processors you will need. More importantly is how you build your tree, and that is NOT a minor effort. Number one, you will need replicas, at least three of each partition in the tree. Number two, enough bandwidth to make sure that replication and synchronization is not impeded. Number three, you WILL have a number of arguments from the management team (if they are one) at the normal number of communication paths within the team, that is N! if they all fight separately, N!/P! if they gang up. These arguments will be centered on who has what access, up to why the tree doesn't place them at the top (hint: follow the organization chart. Get the CEO to tell HR to give it to you.)
After that, it's really a matter of studying the available literature. Get a copy of the X.500 documentation to understand the standards for update and replication, and after that, try a couple of test implementations in a little three server lab. You can probably do that on a couple of one-lung PCs to get a feel for what the tree will look like and how to manage it. I haven't had a test lab in my house in a couple of years, but the last one was an Athlon laptop with OES 1 on it. Get a copy of NDS Basics from Novell Press and bone up. The other book useful to this effort is Open Enterprise Server Administrator's Handbook also from Novell Press. Grab an eval copy of OES and practice. When you go live, the price of the eDirectory component itself is worth the cost of OES.
davel
dot-sig.
open directory ... http://www.apple.com/server/macosx/technology/opendirectory.html plug it in, turn it on, and it works. only downside is that you are limited to apple hardware.
Looks like these vagina pictures you find in the gents rooms worldwide.
Yes, I realize it's supposed to be a brain, but just saying, just saying..
I have been running 2 heavily used (20k users) OpenLDAP implementations for about 5 years now. Runs great.
Hello all At our company we have a big AD domain with 35 domain controllers. When AD was introduced we had o disable our unix dns server because windows comes with everything in it. So yes we build a few data centers with AD. Now we are also running a few hundred linux systems for SAP. We had to connect to AD because we already have that. So we were connecting our systems to AD with winbind and now it seems wibindd can't handle the load. People can't login so we have to trouble shoot that.When asking our AD guru's the only answer you get is everything is working fine ;()())&@%$#... Now we are going to only use the kerberos stack from AD in the AD domain, and authorizations will be done in our own directory. For other environments where we haven't got AD we are going to use our own kerberos/directory domain. The next step will be a solution like freeipa because why shouldn't we use our own native authentication services. Radius and LDAP have been used for years and are proven technology's. Kerberos can be used for authentication and bind 9.5 also supports gssapi to do ddns updates. So disable those windows ddns and stay at the save side before you can't disconnect your systems from AD because it is the defacto non standard. Use open software for your open servers. And let windows use their own directory services. Also you can use windows password sync for project 389 if you wanna have password synchronization.
People before you know you can't get rid of AD anymore and you are forced to buy MS products. Check out zimbra for email and use apache for web aplications it's not hard and the performance is great.
A unix researcher;)
I'd take a look at Novell Directory Services. I think it's called eDirectory now. Although the company I work for has almost exclusively windows based environments, I'm not a fan of the Jet database engine or its derivitaves many of these services are based on. If Windows users and PC's are in the minority, NDS would probably be an ideal solution.
Aside from your current mix of boxes, you have to consider other things from other vendors in the future (present?).
Think of:
1) IP-PBX connected to your directory to auth users
2) firewall, to define rules based on users, not IPs. (same for other firewall-like features such as VPN)
3) management platforms, CRMs, ERPs, where you'll need RBAC
And many others.
While some of them can connect/use/sync to any LDAP-compatible directory, some (most) others are just certified to work with Microsoft AD.
If you feel there's a lack of openness, set up a secondary RH, Fedora, OpenLDAP, whatever and sync with the AD. Or do the other way round, AD sync'ing to the open LDAP, but I would recommend having a usable Microsoft AD somewhere in your network.
What you have here is a chance to implement a proper Identity management system.
The effort you intend to invest is comparable to that required to implement a system such as IBM's Tivoli Identity Manager. This will give you a central point of administration like a directory service, but also allow you to cleanup, manage your user ids, implement role base access, use workflow to perform Business need reviews, employment verification and that's just for starters.
I am implementing OpenSSO in my office, and we use the SUN Directory Server (instead of OpenDS). They seem to work very well. Integration with AD (if you really need it) is easy to do. Both OpenSSO and OpenDS are available at no cost. You only pay for the support, and the publicly available knowledge base is usually good enough.
I am Linux And Windows 7 was NOT my idea !
Our company went for openldap because we weren't getting any money at the time. Everything was running Debian on old workstations. A few years later, we got money for hardware, and we've built around what we had and ended up with quite a cool setup. Pretty much all based on Debian stable and FOSS. I haven't used AD before, so I can't say openldap will be better, however it pretty much does what we need it to. We have e-mail routing based on ldap attributes with postfix, authentication and authorization for courier-imap and pop, apache http auth, intranet (drupal), bugzilla, Request Tracker, kbox, jabber... Recently, we got some Cisco ASA's for vpn client usage, which can do authentication and authorization based on LDAP. For the Windows machines, we've got a domain with samba 3 that uses openldap as backend. That works great. We just don't have group policy, which would be nice to have, but I've read here that it ought to work even with samba, so maybe we could look into that as well. All of our ldap traffic is nicely secured with TLS and SSL, and the datase is replicated to a dozen LDAP slaves in all of our worldwide offices. We also query the db for contact details from the mail client and our contact page on the intranet, as does our avaya phone system to find phone numbers and even some of the fax machines we've got. (And address book/mobile phone sync) We also don't have to worry about licensing, which is quite nice when you want to try something out with a testbed or want to do some redundancy.
Take your machines that are running AD, and then follow the example of the Office Space staff when they brought the Fax Machine/Printer to the park. Don't forget the rap music too.
After that, use the already existing open-source solutions on a Linux box.
It's the right thing to do.
... aka DSSE, etc. - see http://www.sun.com/software/products/directory_srvr_ee/index.jsp
I don't know - just asking. It's free-as-in-beer, you can (presumably) buy support from SunOracle.
Discuss.
Uh huh. So what's wrong with AD?
Microsoft seems to design their protocols to be as hostile as possible to 'other' OSs (without being openly anti-competitive). This is good for their business plan but bad for users. A side effect of this is (like another comment in this thread noted), that it's really difficult to expand the system beyond what Microsoft wants you to be able to do.
Given that you're using mostly 'other' operating systems, I think it would be a big mistake to make the bulk of your systems beholden to a hostile mistress.
Free Software: Like love, it grows best when given away.
There is no ONE directory services that is optimum for every use case. If you want to manage large numbers of Windows workstations then you need AD. If you want to do high performance LDAP then you need eDirectory. If you want to manage authentication to Oracle DBs the you need OID....the list goes on. This is why for any non-trivial implementation you need Novell Identity Manager which allows you to use the right service directory for each of these applications but enables you to manage your environment as if it was a single homogeneous directory. Note...I design such systems for the largest environments in the world. The largest production implementation I've worked on is in excess of 400 million identities.
I have many of the pieces, but seem to be lacking the glue to pull it all together. Do you have your experience documented anywhere? Can you post it to a newsgroup/forum/wiki somewhere so that the rest of us can benefit?
The OP mentioned that "we are primarily a Linux shop, there are a handful of Windows systems that will be on a Windows Active Directory domain".
Does every machine that authenticates to an AD server need a Windows client licence? Or every user? Does the AD server need an additional client or user licence?
I haven't bought client licences for years -- it was back in NT4 days -- but as I recall they were pricey and hard to get. And nobody was prepared to go on the record about how to calculate how many I needed. (Although several people said things that were vague and inconsistent and then stopped returning calls.) Maybe that has changed.
Try OpenDS as well.
eDir is hands down the most sophisticated directory platform on the planet. It beats AD's flat file any day of the week. It runs on Windows, Unix, Solaris, and Linux. Most of the troubleshooting and setup documentation can be accessed for free, and without creating huge, distributed, complicated setups, runs problem free as well.
With the latest version, an eDir box can belong to an AD domain, or an eDirectory tree. Without support, eDir can be had for free.