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!

Just want to blog this article about using Restricted Accounts And Vi(m) Tricks in Linux And Unix to increase security and limit the tricks people can do by breaking out shells and editors. For instance, if people or processes need to be able to write in a specific location on your system, and you want to lock them down as far as you can, you could use a chroot jail together with a restricted shell to limit their options completely.

A never ending problem when you run Linux in the enterprise, is security (and stability) of the systems and access control to allow users, contractors, developers to install software and create or tweak configurations so that some application or service runs. Ideally, only you the sysop can install or configure software and everyone else has to turn to Using sudo , you can define tons of ways for users or groups to be able to run (or not) some commands on some or all systems. You can setup that they may run commands as other users without needing their password. Or you can turn off passwords all together. However, as soon as you start building a list of commands that a certain user or user group can or cannot run, you create the possibility for knowledgeable hackers users to work their way around your system by creating loopholes, symbolic links or abuse buffer overflows. Perhaps, we should all use sudo to allow or deny general access to machines or users and use consolehelper to cre...

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

Funny, I was searching for this last Summer but couldn't find a good way then. Now, I found instructions on Red Hat for forcing a Linux user to change his password on first login ! It's easy too and along the lines I was thinking then, but simply couldn't put together. Create the user, set a password, lock the account, use chage and unlock the account...

At last I found a way to debug the usage of sudo and my sudoers file! It was there all along but I must have overlooked it million times... When using the option -l for sudo, you get a listing of the allowed and forbidden commands for that user on that host. Thanks to the [sudo-users] list for showing the light. As there was no mention of the word "debug" anywhere in the man page, I simply overlooked that option all together... *sigh*

While searching the sudo manual for samples and explanations, I discovered that my Oracle Enterprise Linux 4 update 5 uses sudo version 1.6.7p5. The official version is up to version 1.6.9p9. Interesting is, however, that the new version has means to integrate with LDAP! That means, that instead of maintaining a central /etc/sudoers file, you can build your authorization tree in LDAP, where you can also handle your authentication! Cool! Of course, by LDAP I mean OpenLDAP , Novell NDS, Oracle OID or even Microsoft AD...

$#%@&%#@$!!! 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...

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

Just to be fair, I've been looking for ways to integrate user, account and policy management between Linux and Windows. I have a corporate Active Directory they want me to adhere to/with. So using AD as the main system, because they know how to maintain it and procedures are in place, I'd couple Oracle Linux's user accounts and groups with AD. Vintela also claims to do this, just like Centrify and Unix Components of Windows Server 2003 R2. But personally, I'm still charmed by PADL's NIS/LDAP gateway. I like using NIS to provide seamless account and access rights management with some other system that uses LDAP. That way I could potentially choose to work with MS AD, Novell NDS or a home built openLDAP authentication back-end.

My investigation of Linux/Windows integration for user authentication also showed that Windows Server 2003 R2 has UNIX Interoperability Components , also for Linux but Microsoft tends to put them all onto one pile i.e. non-Microsoft. The UNIX Components claim to be able to give a Kerberos trust between Linux and Windows servers, probably through winbind. It has Active Directory (AD) schema updates for NIS and Kerberos authentication and lets NIS slaves sync with the AD. Using Identity Management for UNIX (IDMU), you also get a Windows-based NIS server... hmmm, I can't help but read "milage may vary" between the lines... We'll see.

PADL has loads of good links to LDAP Documentation for various parts of the process of tying Linux into LDAP authentication, with or without the use of Active Directory NOTE: PADL also offers useful (and free) NSS and PAM modules on their site.

When diving into Linux user authentication and authorization, you will definitely need to read the PAM documentation .

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

Found another set of Conversion Tools for LDAP , many free (GPL) and some commercial. Bottom-line: LDAP is a safe path to build and store your authentication directory information with/in. You can easily (relatively) convert form LDAP to standard Linux passwd and shadow files, or to NIS...

Been looking some more into the user administration issues I face when maintaining a few hunderd Linux servers for various people, customers and developers... Centrify seems to have a nice product that allows me to authenticate Linux users against an (existing) MS Active Directory Server (AD). While that is nice, it is not enough. Granted, their DirectControl family of products covers a lot and is nice, what I miss is the ability to control which user can issue what commands on a Linux/Unix level. That is, DirectControl does not seem to link into the su/sudo/sudoers facilities of Linux. NIS is a common way to centralize Linux user management on a network and control access to servers, do password management and so on. However, I thought NIS was largely incompatible with more common, cross-platform directory solutions such as LDAP. Even MS AD can talk LDAP! ;) So I was more than happy to discover that PADL provides free toosl to help migrate from flat access files (passwd, NIS, etc.) ...

Where strict corporate access, authorization and authentication mechanisms are in place, user access rights must be managed carefully. Linux is no exception. In full Unix/Linux houses, this is not really an issue. But in mixed Microsoft/Linux environments, I still find it daunting to get Linux servers properly added to Active Directory realms, domains and so on. SAMBA and winbind do a wonderful job, but sadly only Novell's SUSE Enterprise 10 server and desktop do it out-of-the-box. (Something to be said for collaborations!) The main problem I find is that while winbind can be used fine, it's never the version that comes with the platform. The reliable, stable Enterprise release alway uses some old version and you find yourself looking for sources, newer versions, packages and so on. Then there is the ignorance of Microsoft techies, who stubbornly won't help because "it just works in Windows" and often don't know how either. Well, with Linux you have to know th...

Having an enterprise Linux platform is one. Having good security is another. I've read myself into sudoers lately, but the possibility of sudoing to root daunted my still. Luckily, it's an age-old problem of course, and a solution is at hand. A forum post from 2001 offered me a good solution for prevention of su to root .