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.
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~
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
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
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).
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.
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
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
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
Plays fine. The problem of the PAC means Linux Kerberos servers cannot serve Windows clients. Nothing to do with the reverse.
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.
tastes like crow!
Seriously though, there are many people that read slashdot that actually have used most if not all of these different Directory solutions. They need to use them because they are professionals that help run companies, Directory Servers, as a class, are the only way to sanely manage anywhere from a couple dozen users and machines to hundreds or thousands of users and machines.
It doesn't matter whether it's OSS vs Closed Source or Microsoft vs Everyone Else, Once you have REAL experience with more than one Directory server, you will realize that AD is truly the "Best of Breed" of Directory Servers.
Bad form I know...
All that being said there are GOOD implementations of AD and there are BAD implementations of AD. LDAP/Directory Servers in general are complicated, it takes quite some time and experience to know how do a Good implementation with one. Same as everything else.
There is also:
Apache Directory
Sun OpenDS
Winter 2010: With Glowing Hearts
" 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>
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...
>>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.
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 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.
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..
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.
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.
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.
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.
Why are you stuck with AD? Its not like you can't get an ldif export out of it to import into something else. If that something else only supports ONE set schema than its not different than AD as far as lockin. All the other reasons you are 'locked in' to AD are going to be things like 'well no one else supports that feature' that would be there if you started with AD or not. If willing to can truly afford to give up those features now to avoid MS than theres no reason the same wouldn't hold true later.
This sort of comment always bothers me. I'm looking for one reason that you'd be locked in that doesn't equate to 'you're locked in because other products provide an inferior solution'.
I don't want to know/care about if MS is using secret sauce and not sharing to make it better for their products, thats their right as a company and has been an accepted business practice for all of recorded history. Its not new and unique to the computer/software industry. If the other product doesn't have a solution that provides cost/benifits than it is inferior for the task. Software will never all be equal or there would just be one. I'm sorry if your beliefs want you to promote software that has a competitve disadvantage of intentionally by design giving away its assets, thats your choice and theres nothing wrong with it, but that doesn't make it better than everything else, it in fact gives it a severe disadvantage. EVERYONE else can communicate with you if they need to, but you can't communicate with them. Who's fault is that? You blame them, but you could have done the same and didn't, your choice, not theirs, you're to blame.
There are PLENTY of very good benefits to OSS and those reasons are why many people support it and use it every day. I'm one of those people. But its not the end all be all, and it does have disadvantages, thats just reality. And thats all your post is about, one of its disadvantages.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager