Mostly Solaris 11 with some 10 and even fewer 8 and 9.
At the moment, NIS is used.
Looking for a better way and to get rid of NIS.
LDAP?
LDAP indeed...
With RFC2307bis schema draft 02 (which is what I think Solaris uses) combined with TLS or Kerberos.
As is in "what is LDAP?" or "Why not try LDAP?"
---------- Post updated at 03:57 AM ---------- Previous update was at 03:56 AM ----------
Current NIS server is Solaris 8. Upgrade this first or leave alone before moving to LDAP?
Looking for least disruptive method....
As : There is no other choice than LDAP if you want to get rid of NIS but depending on your expectations, it might not match what you mean with "a better way"
You do not tell why you want to drop NIS. It's a 33 year's old service so neat it even survived its successor (NIS+).
If you look for a smooth transition, it can be achieved by setting up the nis2ldap service. It requires an ODSEE backend.
OK maybe its not better lol.
Mainly for security issues and because its unsupported. After all, we're also running on a pair of solaris 8 servers.
Hi,
My take on this would be that if you actually have a functional need to move away from NIS for some reason (i.e. you're adding a new server, service or application that doesn't support it, but which could integrate with, say, OpenLDAP just fine), then sure, get rid of NIS. But if NIS is working for you, then there's no real need to replace it with something else.
If your NIS server is running Solaris 8 and is now unsupported and unpatchable, but the rest of your environment is running supported versions of Solaris and is already integrated with the NIS domain, then the real problem is Solaris 8 rather than NIS.
In that scenario it would definitely be easier and less work to migrate the NIS server service onto a currently-supported Solaris box and just leave the rest of the NIS environment intact, I'd imagine.
Yes, still running Solaris 8 (end of extended support 2012) and 9 servers (end of extended support 2014) means security is not a top priority in your shop.
Moving to LDAP is definitely the recommended way to provide secure distributed authentication but that's not something you do overnight.
Is your environment only using Solaris or also other Unix/Linux OSes?
Do you already have an ldap service somewhere? Does it already contains entries for your unix users?
Do you require a commercially supported solution?
1 Like
Well I'm a contractor whos been brought in the last few months....
Solaris and also RedHat. But they also have Windows - but its likely they will want to keep windows separate.
Yes it needs to be commercially supported.
What Windoze calls "Active Directory" is in fact a (very stripped-down*) ) LDAP domain with Kerberos V authentication. You can use a regular LDAP domain to feed info to the Windoze domain because it is essentially the same.
I hope this helps.
bakunin
___________
*) What i mean by that is that, for instance, a usual attribute for a user record is "login shell", which usually points to /usr/bin/ksh , /usr/bin/bash or something alike. In the original "Active Directory" this entry misses and because you cannot change the structure in Windoze you cannot use the Active directory information to authenticate UNIX/Linux users. You will (and should) do it the other way round therefore.
The only Oracle fully supported solution is to use ODSEE (simplest because there is a specific command designed to ease the configuration: idsconfig) or OUD. Some other LDAP servers would work but AD probably won't.
Hi,
Out of interest: what is the actual brief from the client, or aim of the project ? You mentioned in your first post the desire to replace NIS with "something better". Is there some specific thing that NIS isn't doing for them, or is the aim just to replace all unsupported systems (of which the NIS server is one) with currently-supported ones ?
Having authentication data travelling unencrypted on the network is likely sufficient to urge admins to look for something else.
Two reasons:-
1) They have the impression NIS isnt working properly anyway. (They wont delete users because it went wrong once).
2) Replace unsupported systems.