Oracle: Unbreak my Linux Heart

Often, when getting started using sudo and /etc/sudoers on a Linux system to authorize users to do something somewhere, you would like to debug sudoers and see why things fail when you think it should work. First, try sudo -l on any system as any user and get a list of things (if any) that you are allowed to do. Check and see if anything is missing. The sudo mailing list also hinted to a way to parse the sudoers file to see if anything is malformed. This can verify at the sudoers does not contain any typos or syntax errors. Finally, and most importantly, know this : "When multiple entries match for a user, they are applied in order. Where there are multiple matches, the last match is used (which is not necessarily the most specific match)." So order matters!!! Start with general rules and become most specific towards the end of the sudoers file. If you grant something at the top and deny it at the bottom, sudo won't allow it for the reason above. In that case, change th...

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

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 had a minor interpretation issue with a paragraph in the Sudoers Manual . So I wrote to the sudo mailinglist and asked a clarification... Here is their answer, which made perfect sense! Thanks! Let's say you have a user, bob, who is a member of a group and sudo has a configuration like: User_Alias ADMINS=bob,mike,tom ADMINS ALL = (ALL) PASSWD: /bin/ps, /bin/ls, /usr/sbin/shutdown -y -g0 -i0 bob ALL = (ALL) PASSWD: /usr/sbin/shutdown This says that bob has multiple entries (in the group and an explicit entry) but the rules say that his last match contradicts the ADMINS. It will give his last match... i.e., he can use shutdown with any argument... if you reverse these entries: bob ALL = (ALL) PASSWD: /usr/sbin/shutdown ADMINS ALL = (ALL) PASSWD: /bin/ps, /bin/ls, /usr/sbin/shutdown -y -g0 -i0 then you have effectively restricted bob to the same command as the other admins. and therefore not given him any special treatment...

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

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.