Forgot your password?
typodupeerror
Networking Software IT

Directory Service Implementation From Scratch? 149

Posted by timothy
from the just-have-everyone-shout dept.
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?"
This discussion has been archived. No new comments can be posted.

Directory Service Implementation From Scratch?

Comments Filter:
  • Easy (Score:3, Informative)

    by ChadAmberg (460099) on Thursday June 04, 2009 @03:29PM (#28213723) Homepage

    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.

    • Re:Easy (Score:4, Informative)

      by fahrvergnugen (228539) <fahrv@hoCOBOLtmail.com minus language> on Thursday June 04, 2009 @03:32PM (#28213779) Homepage

      This. AD's management tools are brutally efficient and understandable. The newest versions of Samba+KB5 make it trivial to authenticate *nix systems against it and have fully integrated, cross-platform user & privilege management with consistent uid's/gid's across all hosts. Assuming you throw the right amount of resources at it (at least 2 AD servers per tree in the forest, per site), and take advantage of the DDNS services, you'll have a really scalable, easily managed infrastructure for years to come.

      • Re:Easy (Score:4, Informative)

        by GPLDAN (732269) on Thursday June 04, 2009 @03:41PM (#28213941)
        Likewise, Centrify, Quest and others (Centrify especially) provide tools for all flavors of Linux, JBOSS Servers, Apache servers, and Oracle databases to all use AD for directory services. Centrify has tools for audit and command control that piggyback on restricted shell.

        It's hard to argue against AD - even in your situation where the Microsoft boxes comprise the minority of systems.
        • Re: (Score:3, Informative)

          by Ralish (775196)
          It's worth noting that Microsoft also has Services for Unix [microsoft.com] (applicable for Windows 2000 through Windows Server 2003) and Identity Management for Unix [microsoft.com] (applicable for Windows Vista through Windows Server 2008).

          While Unix boxes can authenticate to an Active Directory domain through the use of Samba and derivatives, the advantage of these services is that they can extend the LDAP schema with NIS attributes to provide native NIS authentication, and also, extend SMB sharing with NFS support to provide native
          • Win2k3 R2 (Score:2, Interesting)

            by Lurching (1242238)

            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.

          • Re: (Score:3, Informative)

            by BitZtream (692029)

            I'd just like to point out that while you CAN use NIS with SFU and the like, unless its an old machine without Kerberos support and without NSS support, you really would want to use kerberos and nss_ldap to connect to an AD server with SFU installed. If you have old machines, sure, shoe horn them in with NIS, thats what its there for, but you should avoid it if possible, NIS is horribly insecure. The plus side of using kerberos is that no syncronization is required, AD will sync its kerberos server passwo

            • by Ralish (775196)
              Functionality wise my understanding is that they are effectively equivalent. My only reason for preferencing IDMU was that my experience has been it is better integrated into the overall OS, and possibly as a result, its installation and configuration was smoother.

              Last time I used SFU was many years ago, but effectively I had some serious trouble installing it on a Windows Server 2003 box that was only setup weeks ago and was for all good and intent vanilla. It culminated in having to do several modifica
    • If you do decide to go with an Active Directory, I found that using Winbind [enterprise...planet.com] was an extremely easy way to have my Samba server authenticate my users from the AD. It was up and running in no time and it's been rock solid ever since.

      One thing to remember is to use Group Sharing [udel.edu] when setting folder permissions on the *nix box. That was an easy one to overlook until users started asking why they couldn't open each others files!
    • Re:Easy (Score:5, Insightful)

      by Savage-Rabbit (308260) on Thursday June 04, 2009 @04:11PM (#28214343)

      Use AD.
      Even though folks will fuss and whine about AD being not pure LDAP...

      You're not a developer, are you? Whether or not AD is a dream to work with depends heavily on what your job description is. If you are simply an administrator plugging random Windows or even Linux and *nix boxes into AD you might find it comparatively easy. If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD. It's not an unsolvable problem mind you, just a really annoying one.

      ... It's simple enough that MCSEs can run it.

      So is RHDS / Fedora Directory Server. I knew exactly nothing about LDAP or directory servers when I got my first directory server related project years ago. I still I got the thing set up and running inside of a couple of hours. Even an MCSE should be able to manage setting it up, hardening it and administrating it in a very short period of time.

      • by wasabii (693236)
        Wait. Problems like what? It supports LDAP and Kerberos. You can query it just fine.
        • Re: (Score:3, Funny)

          by Rysc (136391) *

          You can LDAP query AD like my moped can race in the Indy 500.

          • Re:Easy (Score:4, Interesting)

            by wasabii (693236) on Thursday June 04, 2009 @08:36PM (#28217151)
            Uh huh. So what's wrong with AD?
            • 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.

      • by Blakey Rat (99501)

        You're not a developer, are you? Whether or not AD is a dream to work with depends heavily on what your job description is. If you are simply an administrator plugging random Windows or even Linux and *nix boxes into AD you might find it comparatively easy. If on the other hand you expect to have to develop custom applications of your own on non-Microsoft platforms that authenticate against AD or convert existing ones to use AD then it can be a painful experience to use AD. It's not an unsolvable problem mi

      • Re: (Score:2, Insightful)

        by Anonymous Coward

        Authenticating against AD is hard? I didn't realize that, I mean, I've been writing apps that authenticate against kerberos since before AD existed, and since those same apps authenticate against ActiveDirectory the exact same way, I must have missed the hard part.

        Hard to authenticate against AD, WTF are you talking about? Do you know how it even works? If you're using some retarded fucking bind against ldap for verifying authentication to your apps? If you use the bind to allow the user to authenticate

      • Re: (Score:3, Interesting)

        I know quie a lot about LDAP, Kerberos, DNS, DHCP, and database back ends. I find Active Directory's pitfalls to be quite painful. (Its refusal to assign a hostname for broadcast or netmask addresses is just plain stupid.) And as you say, custom applications are difficult. (Try deploying djbdns for mail filtering of the dnsbl blacklist with Active Directory in place. Oh, dear, that was painful!!) But _everyone has clients that will work with it_, And if you need a bit of your own services, such as a local
    • Re: (Score:1, Interesting)

      by Anonymous Coward

      The problem with AD is lock-in. Once you deploy AD, you will never be able to switch to another directory product, as Microsoft software dependency creep will ensure that no other product can operate as a drop-in replacement.

      If you only have a few Windows machines, use a standardized solution and live with loss of MS-specific functionality. If you deploy AD, you'll soon find yourself locked in, and the investment in MS-only technology will only keep growing.

      • Re:Easy (Score:4, Insightful)

        by fractoid (1076465) on Thursday June 04, 2009 @11:52PM (#28218243) Homepage
        At least part of the lock-in from Active Directory is the simple fact that it's a comprehensive system that can be managed by someone with very little experience. You ever tried teaching yourself in a week of on-the-job "how the f**k do I do this" how to run a mid-sized office network? I have. Using Active Directory and with no prior sysadmin experience it was possible, if a little rough. Trying to do the same thing using open source software would probably have taken me six weeks rather than six hours to start getting results. And even then, I'd have spent weeks looking up obscure config problems and installation how-tos.

        To someone equally fluent in both OS and MS systems, sure, an open source solution is fine, probably even superior. But the business case for using MS software is undeniable.
    • Re: (Score:3, Interesting)

      by ogrius (186951)

      The other thing you can consider is whether to split the directory services and the authentication.

      At my last job we did the following:

      - Use Windows AD for all windows machines
      - Use NIS for passwd, group, automounter maps... everything but authentication.
      - And then key the Linux machines to use Kerberos off the Active Directory

      Now if I was doing it again, I'd do the following:

      - Use Windows AD for all windows machines
      - Setup up a UNIX/Linux based Kerberos domain that "trusted" by the AD Kerberos
      - Use NIS, NI

    • 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
  • Just go with AD (Score:4, Informative)

    by anom (809433) on Thursday June 04, 2009 @03:30PM (#28213757)

    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

    • by Seranfall (680430)
      I completely agree. If your a full linux shop and money for server software is an issue than OpenLDAP or something similar may be a good solution. However, with windows clients in the mix you should definitely stick with AD. Just about anything will interface with AD in some manner. Also there is far far greater support for AD then your going to find with any of the other directory services out there right now.
      • by cowdung (702933) on Thursday June 04, 2009 @03:45PM (#28213995)

        Wow.. did I wake up in another dimension? Are slashdotters actually recommending MS products today??

        • Re: (Score:3, Interesting)

          by alen (225700)

          AD and OpenLDAP are like first cousins.

          big difference is Open LDAP you have to create your schema. with AD Microsoft did the work for you and upgrading is easy. if you first deployed AD with Windows 2000, upgrading to later versions of windows and AD apps is easy. MS ships ldif files with any of their apps that extend AD with new classes and objects that do this automatically. saves you a lot of time.

          • Re: (Score:3, Informative)

            by afidel (530433)
            AD also does multi-master replication out of the box and it's been scale tested to the very largest of implementations.
        • Re:Twilight Zone? (Score:4, Insightful)

          by sloanster (213766) <ringfan@@@mainphrame...com> on Thursday June 04, 2009 @05:21PM (#28215149) Journal

          Wow.. did I wake up in another dimension? Are slashdotters actually recommending MS products today??

          But of course - did you not realize that the majority of slashdot readers are microsoft windows users?

          • by jdunham (446838)

            but what about the majority of slashdot _writers_?

            • by bar-agent (698856)

              but what about the majority of slashdot _writers_?

              They don't use Microsoft or Linux. The monkeys all have Remington typewriters, and we feed them bananas, Jolt cola, and yesterday's pizza.

        • Re: (Score:3, Funny)

          by serutan (259622)

          Ohhhh Barnacles! It's Backwards Day!

        • by Zumbs (1241138)
          Just this day, a spaceship landed and from it walked an army of Bill Gates-drones. Each of them were a part of a large, but simple plan: Find a computer, hack a slashdot account, and good-mouth everything MS. However, some of them adabted to this brave new world, and wrote their praise with reluctance to veil their plans from the *nix'ers ... but they are out there, and if you get in their way
    • Re:Just go with AD (Score:5, Insightful)

      by dpilot (134227) on Thursday June 04, 2009 @04:03PM (#28214249) Homepage Journal

      I've looked into LDAP/Kerberos authentication for my home LAN several times, and basically given up every time. There appears to be a software mix that will do the job, but each piece needs to be configured *just so* in order to work with all of the others. Furthermore, there appear to be a few people out there who really know their stuff, and to them I'll bet this is all easy.

      But it appears that those people all work for companies that sell Directory Server services. They're quite willing to be helpful on specific questions, but the overall integration is still not well documented, from what I can see. As near as I can tell, it's like the Bad Old Unix days, when everyone wanted to be The Solution - for a price. I haven't really looked at the RedHat Directory server or similar products, wishing to use the pieces, and wishing for integration documentation.

      Why this on a home LAN? For some odd reason, I've tried to run my LAN on industrial-strength software - BIND, ISC DHCP, etc. I'm used to single-sign-in at work, and would really like it at home, given that $HOME is shared over NFSv4. I also usually am too busy doing other things, which is another reason why there's been no progress in years.

      Maybe an integrated OSS Directory Server will make it into my house, but there's no way I'm footing the bill it would take to add AD, here.

    • Re: (Score:1, Interesting)

      by Anonymous Coward

      The main pitfall is to be careful about the MS licensing rules for AD. You essentially need a CAL for EVERY USER in your directory, or some of the crazy very expensive CALs. This is no big deal if you already have CALs, but it would be insane to use AD for something where the users accessing the server are not employees of your company. The licensing costs would become crazy when compared with something open source.

      • by 222 (551054)
        This claim smells funny to me. Can you provide any reference to per LDAP user CAL licensing?
        • by BitZtream (692029)

          MS is pretty clear, any connection to a Windows server requires a CAL, period.

          • by BitZtream (692029)

            Let me restate. Any client that makes a connection to a Windows server requires a CAL to access the server. Its not per connection in most cases (is in some though!), but if you're connecting to a Windows server, you need a CAL to account for it somewhere.

            Windows server web edition has some allowances to keep the CAL count lower, but since it doesn't run AD its not part of the discussion here.

        • 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, rea

        • Re: (Score:3, Informative)

          The licensing for Windows Server doesn't necessarily have anything to do with the size of the directory.

          With Server 2008, you have a matrix of options. You can choose whether you want to count licenses by computers or users by the type of CAL you buy (Device or User). Then, you can choose whether you want to license the number of simultaneous connections to a single server (per-server) or by the number of discrete users or devices that have accessed any server (per-user or per-device). Clearly, if you only

      • by CAIMLAS (41445)

        It's been a while since I've looked at Windows licensing, and they do tend to change things from version to version, but I seem to recall that MS offers two client/connection licensing models (which are mixable): per-server or per-client. At the least, Windows Server only tracks licenses by concurrent connections to the server in per-user licensing. They might also offer a per-domain model.

        It's all pretty convoluted, I'll give you that.

  • by perotbot (632237) on Thursday June 04, 2009 @03:33PM (#28213799) Journal
    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
    • Re: (Score:3, Informative)

      by Anonymous Coward

      +1 On Novell's IDM, it is *hands downs* the best Directory Services product out there.

      Though if you don't want to spend the bucks for it (it's worth it, seriously), I would recommend just using AD.

      As others have said, AD just sort of works, and everything can interact with it.
      I'd personally recommend it over SAMBA/OpenLDAP, as I've beat my head against the wall one too many times trying to use SAMBA/OpenLDAP as a Windows Domain. It's just not worth the time or frustration.

      • Re: (Score:3, Interesting)

        by JSG (82708)

        and +1 for eDir from me as well.

        I have a blackbelt in directory management (AD, eDir and OpenLDAP)

        eDirectory has a nasty habit of being virtually unkillable and is by far and away the most flexible. With 8.8 you can run multiple trees on a host (in MS speak think of multiple domains on a single DC) No waste of a system to just do DC duties for one bit of your system.

        If you want the most powerfull directory option then use eDir as your metadirectory and then use IDM to populate other directories and applic

    • by Techman83 (949264)
      Yeah we administer AD using IDM. Everything gets done in eDir, which is much faster and less frustrating, then it flows onto AD automatically.
    • by Rysc (136391) *

      Second!

      If you're not going with a F/OSS DS, eDirectory is the product to buy. By itself it's great, with Novell's other tools it's even better. And it supports Windows clients, so no trouble there. If you're thinking "A directory server is a directory server, AD is good enough"--DON'T think this. There is such as thing as better and eDir is it, vs. AD or OLDAP.

  • My choices (Score:4, Informative)

    by xaoslaad (590527) on Thursday June 04, 2009 @03:40PM (#28213913)
    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.
    • Re: (Score:3, Insightful)

      by gbjbaanb (229885)

      would it not be possible to configure a single server, that proxies or delegates queries to all the other servers he has set up.

      I asked about proxying openLDAP to AD, so I could have users in both, yet query them all just by asking the openLDAP server. If this was possible for multiple delegated servers, then this is the approach I'd take - start with 1+all the old ones, then gradually migrate them into just a few servers.

      and yes, I'd probably go for RHDS, Active Directory seems to be one of those products

      • by Tmack (593755)

        would it not be possible to configure a single server, that proxies or delegates queries to all the other servers he has set up.

        I asked about proxying openLDAP to AD, so I could have users in both, yet query them all just by asking the openLDAP server. If this was possible for multiple delegated servers, then this is the approach I'd take - start with 1+all the old ones, then gradually migrate them into just a few servers.

        and yes, I'd probably go for RHDS, Active Directory seems to be one of those products that starts off with just a windows 2008 server, then requires more CALS, then needs a SQL Server licence, and then really expensive backup software, and then needs all printers to be connected to it, and then needs Sharepoint adding to the mix, and then... you get the idea :)

        OpenLDAP has a few backend plugins that let you do crazy stuff like that, more specifically, the LDAP backend lets you run a proxy to AD (or any other directory that can talk LDAP). Set that up, map a few attribs or get the AD schema on OpenLDAP, and you should be good to go. You can also sync to AD, so if your link to it goes away the data is still local. OpenLDAP has come a long long way in replication, and it works quite well now, much better than even just a year ago. Set one server up with your data, t

    • Re: (Score:2, Informative)

      by IMightB (533307)

      SunDS, FDS and Novell eDirectory are all based on Netscapes DS,

      FDS and RHDS are the direct descendants of Netscape DS, which was purchased by AOL and then by Redhat who then Open Sourced it.

      • Re: (Score:3, Informative)

        by Clover_Kicker (20761)

        SunDS, FDS and Novell eDirectory are all based on Netscapes DS,

        Uh, eDirectory is the current name for NDS, which came out with Netware 4 in 1993, before Netscape was even a company.

      • by JSG (82708)

        eDirectory AKA NDS was based on X400 as I recall. I remember using it in 1993, before Netscape was formed - "Netscape stock traded between 1995 and 2003" - Wikipedia

      • SunDS, FDS and Novell eDirectory are all based on Netscapes DS

        Timeline issues notwithstanding, I think you're confusing Novell Directory Services and Netscape Directory Services. The former came before the latter, although they both have the same acronym.

    • by d235j (1434583)
      Yes, I agree that RHDS/FDS aka. 389 directory server (directory.fedoraproject.org) is probably the way to go.
    • by JSG (82708)

      >>4.) Novell eDirectory (personally my least favorite)

      Why? Have you actually used it. How does it compare to your other options?

      • by xaoslaad (590527)
        It's not the product that I necessarily have a problem with. I've had bad experiences with Novell support, as I said in my original post. I also said others (probably you) may disagree.
        My experience with Novell have tended to yield the result that their software can and does work, but you can't rely on their phone support for anything. I've actually had them tell me a file on a sles server wasn't part of their distribution, which I countered with a couple rpm commands; to me that's just a sad thing to di
  • 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 Ballme
    • by jaseuk (217780)

      I'd question the logic in apply fruity open source solutions to a startup. A Microsoft Small Business Server is relatively cheap (£800 for first 5 CALs, then around £60 for additional users) and provides pretty much everything you'd need for e-mail, groupware and server functions. It can be supported by any competent local computer shop.

      Open source for a startup or small business pretty much guarantees that you'll need a highly skilled systems administrator from the outset. When y

  • AD (Score:2, Informative)

    by Malenx (1453851)

    Microsoft has really done well with developing AD.

    It's just honestly the best product out there currently.

    • Re: (Score:1, Flamebait)

      by DaveV1.0 (203135)

      That sound you just heard were a thousand fanboys lighting their flamethrowers.

      • by ckaminski (82854)
        Yeah, but he's got a point. It really is best-of-breed. Frightening, no? In terms of interoperability, it wins hands down. Throw GPOs on top, and you have a compelling tool that the OSS movement just can't compete with (yet).

        Too bad it's $700 to get started.
    • by Rysc (136391) *

      You have got to be kidding.

      AD is best only if you mean it's easy for a monkey to do the initial setup. If you want robustness, scalability and maintainability you will find nearly everything else is better.

  • 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.
  • Support (Score:3, Insightful)

    by Cyner (267154) on Thursday June 04, 2009 @03:56PM (#28214161) Homepage

    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.

    • by codepunk (167897)

      No Linux support? What do you live in the middle of the Sudan?

      I live in one dinky little town and one phone call I would have a Linux Engineer on site
      in under 60 minutes.

    • by Majestix (41486)

      Find someone to come in and tell you,

      "Ah, we can fix this. We'll just replace it with an MS AD server. Oh wait, you want to keep this? Why ever for?"

      Those are a dime a dozen. Well ok, considerably more than a dime. But they make themselves sound soooo wonderful...

  • 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

  • Start with SQL (Score:3, Interesting)

    by unified_diff (1139065) on Thursday June 04, 2009 @04:13PM (#28214365)

    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 [usit.uio.no]. 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).

    • Re: (Score:2, Interesting)

      by Tildedot (137711)

      +1 to this. Extremely flexible.
      We do all of this, except for plain text passwords in tables.
      We highly recommend encrypting, or completely eliminating, plaintext passwords. Instead, create and store the required hashes (ssha, etc.) for various bits and pieces when you create a user, or the user changes their password.

    • 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..

    • Re: (Score:3, Insightful)

      by Tmack (593755)

      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.

      slapcat > myldaptree.ldiff

      Done. You now have an Ldiff file that can be re-imported directly, or parsed quite easily, not sure why Exporting seems difficult?

      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.

      gssapi/SASL, or if its a horribly broken ap that doesnt do that either, its trivial to write an authorize/authenticate plugin for it, just about everything supports LDAP though, or "AD" which is usually LDAP with the MS schema in mind that can be bent to use a normal LDAP directory instead. Password sync (to get the broken NT4/LANMAN and KRB5 pas

  • 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.
    • Re: (Score:2, Insightful)

      by JSG (82708)

      >>All of hte other solutions require massive hand holding

      Your experience of these is what exactly?

      Personally I'd use eDirectory. I have 15 year experience of eDir, AD and OpenLDAP. My experience of eDir is that it is worth the cash compared to the rest.

  • 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" :)
  • Hear me out (Score:5, Informative)

    by BitZtream (692029) on Thursday June 04, 2009 @04:47PM (#28214727)

    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

    • by illumin8 (148082)

      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

  • by Anonymous Coward

    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 sup

    • by nexex (256614)

      There is also:
      Apache Directory [apache.org]
      Sun OpenDS [opends.org]

    • Re: (Score:2, Interesting)

      by adriccom (44869)

      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.

  • 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.

    • by wasabii (693236)
      Plays fine. The problem of the PAC means Linux Kerberos servers cannot serve Windows clients. Nothing to do with the reverse.
  • " 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

    • by BitZtream (692029)

      Don't forget that you'll actually want kerberos for authentication. If you're using ldap for the authentication part, you're doing it wrong, sorry. Obviously there are those situations when the app doesn't support kerberos, but if it does and you're not using kerberos, you're doing it wrong.

  • 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 requ

    • by dave562 (969951)

      Do you have any documented cases of where what you are scared of has actually happened?

      The closest I've seen was the battle between Novell and Microsoft back in the mid-1990s. On NT4 workstations, every time a new service pack would come out, the Novell networking client would stop working and you'd have to revert to Microsofts "Client for Netware Networks". After six months or so, Novell coders would catch up, release a new version of the client, and then life would be good again... up until the next ser

  • 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 y
  • 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

  • Directory services (Score:2, Interesting)

    by dlawson (209945)

    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 di

Fools ignore complexity. Pragmatists suffer it. Some can avoid it. Geniuses remove it. -- Perlis's Programming Proverb #58, SIGPLAN Notices, Sept. 1982

Working...