Oracle: Unbreak my Linux Heart

Central user administration has been a long desired feature by me for our data center. MS AD does it all for Windows, but Linux has been all stand-alone so far. I tried to do something quick with NIS in the past, but it never quite took off. So it's just me own (mngt and monitoring servers). For this year, Identity Management was made an issue. However, which one is still up in the air. AD, Oracle's OID , Centrify or just plain an simple standard openLDAP ? From my own experiences, openLDAP is great but distributions are behind on the latest official releases and this can wreak havoc in some obscure but critical situations. So time to read up on the subject. Someone recommended the IBM Redbook Understanding LDAP - Design and Implementation to me... Interesting!

The sudo mailing list sent a message with instructions for using your Microsoft AD server (aka Domain Controller) as an LDAP host for hosting sudoers. I.e. integrating sudoers in an LDAP server so authentication and authorization on Unix/Linux servers can be managed in a consistent, central way. "Using LDAP to synchronize Users, Groups, Hosts, Mounts, and other commands across an enterprise can greatly reduce the administrative overhead." [from the sudo site ] This way, you extend the AD schema and prepare it for inclusion on your system-wide sudoers file. You then use or switch to an LDAP-enabled sudo version and from then on, access to your *nix hosts can be controlled through LDAP (nothing new there), but also authorization to let certain users use certain commands on certain hosts can be controlled from that same LDAP host. In this particular case, that LDAP host can be your existing Microsoft AD server, which many Unix and Linux administrator have to deal with anyway.....

$#%@&%#@$!!! I was having an issue with existing local user accounts on my NIS test server. As indicated in /etc/nssswitch.conf , local files override NIS settings. So starting with a clean system - as far as user accounts go - is a great idea. However, I was also using the local system group wheel for daily management purposes. So it goes without saying that I was confused as to why my own account did not get wheel permissions on my test server. Doing an " id myuserid " on the NIS server showed uid=500(myuserid) gid=100(users) groups=10(wheel),100(users) , while the same command on my NIS test server showed uid=500(myuserid) gid=100(users) groups=100(users) . What gives? Well, there is a file called /var/yp/Makefile that lists which UIDs and GIDs will be transmitted i.e. synced over NIS. Default is 500. So any user account and group below that will not get replicated. *sigh* I did read that while installing but forget when testing. An old Pipermail archive pointed th...

After restarting my NIS server, I suddenly started getting weird errors on commands that worked before... The fix was easy, but so hard to find (Thanks Google!) When doing ypmatch nisuser passwd , I got the error: " can't match key nisuser in map passwd.byuid. Reason: Internal NIS error. ". This was caused by my /var/yp/securenets setting. I had forgotten to allow to the NIS host itself to query the database. Doh! Check the Unix Manual Page for securenets and look closely at the specification of netmask. It says that the mask may also be the string 'host' to allow a specific host access! All I needed to do was add "host 127.0.0.1" and it worked!

I got NIS working last week, but simply following HOWTO guide from Linux Home Networking. Thanks guys! Only difference was that I explicitly defined /etc/securenets and did not need to set the NIS_DOMAIN_NAME as the server opted, but used my existing domain name instead. So instead of setting /etc/sysconfig/network to contain something like NIS_DOMAIN_NAME=MY-NIS-STUFF , I used the same name as my subdomain, i.e. NIS_DOMAIN_NAME=sub.domain.tld . After that, I started the NFS auto mounter on the clients, ran authconfig to set authentication to NIS (don't enable shadow passwords over NIS!) All that remains to be done, is testing, testing and testing, securing NIS for now, setting up a good, solid sudoers file and try to get Oracle's OEM working with NIS... (Hint: test or debug sudo with sudo -l ) Update: do yourself a favor and userdel and groupdel all local accounts or groups (except root) on your to-be NIS client(s), or at least prevent a NIS user from having the same nam...

After political and time pressure not to pursue any commercial products to integrate Linux user authentication into MS AD, I'm falling back to my original plan to set-up NIS(+) for now and deal with AD later... I followed instructions at Linux Home Networking and got the NFS server running but would get an error when logging in as a user: "unable to chdir to home directory". Fortunately, it seems a common error when using NIS and NFS (and Kerberos). It turns out my NFS client wasn't correctly configured. The automount file /etc/auto.home for /home listed my subnetwork (10.X.0.0/16). That's what I had the NFS server configured for. The automount file should just list '*' there... Next is NIS...

While setting up a schema to handle Linux user authentication and authorization using our big corporate Windows Active Directory (AD) server, I ran across a TechEd session that mentioned Scott Lowe's blog. On his very nice looking tech blog, I found a great article describing clearly how to integrate Linux into an AD running on Windows Server 2003 R2. Mind you, Server 2008 - the next release - will be somewhat different and older version of Windows Server as well. It mainly has to do with the RFC2307 or the Server for Unix (SfU) from Microsoft.

From the LPIC pre-exam tests by snow.nl , I got an idea confirmed that one should be able to implement a layered "fall-through" user authentication schema using PAM in Linux. The idea was to maintain a small set of power user and sysadmin information in NIS, because NIS provides access control as well as authentication and ties into su/sudo/sudoers at the OS level. LDAP would be used to maintain and administer several hundred or thousand accounts for customers, vendors, suppliers and other people who need access to certain machines or control specific services (such as web, application or database servers). The PAM authentication (2.210.4) from snow.nl outlines just that. Utilizing PAM's fall-through mechanism, you first check authentication credentials using NIS (sufficient), if it fails you check LDAP (sufficient) and finally the OS itself (required).