Tag Archives: sysadmin

Encryption Types Order in Kerberos

Posted on by
1

Things I don’t wish to forget the next time I need them.  In a Kerberos Realm with multiple encryption types available the KDC will use the first type in the list that’s compatible with the client.  So let’s say you are adding encryption types to your KDC, of course you need to add new keys to the krbtgt/<REALM> principle.  Once you do so check out the list of keys.  What will the KDC chose to use if things are in this order?

Key: vno 2, DES cbc mode with CRC-32, no salt
Key: vno 2, AES-256 CTS mode with 96-bit SHA-1 HMAC, no salt
Key: vno 2, ArcFour with HMAC/md5, no salt
Key: vno 1, DES cbc mode with CRC-32, no salt

You guested it, des-cbc-crc!  The weakest type.  Even when the AES encryption is compatible with the client.

This is where I began to bang my head on my desk.  The order is, of course, set when you use the change_password command in kadmin or via the kpasswd tool.  The order is read from the supported_enctypes variable in your kdc.conf.  So make sure the encryption types listed for that variable are listed in the order of their strength.

Unfortunately, there’s no way to fix the order.  You need to correct the order in your kdc.conf file, restart the kadmin server, then use the change_password command again (with -keepold) to rekey the krbtgt/<REALM> principle.  Or use the kpasswd tool to update your principle.  Yes, the restart in there is required.

Site Local Gconf Customizations

Posted on by
Reply

I’ve been customizing the Gnome Gconf defaults for my local site for quite some time now. The Gnome manuals are quite clear about how to use gconf.xml.mandatory and gconf.xml.defaults to alter the default Gnome settings. For example, I like the weather applet included in RHEL 6′s default desktop but I’d much rather it show the weather for Raleigh, NC rather than Boston, MA. My user base also really appreciates having a terminal launcher on the Gnome panel in their default desktop.

Until our RHEL 6.0 upgrade to 6.1 completely reverted a lot of my customizations.  Sure enough, the gnome-panel package now somehow believes that it can use a %post script to nuke the panel settings in gconf.xml.defaults and replace them with its pristine versions. Its a lot cooler in Boston than it is here in Raleigh.

I filed a bug in Red Hat’s Bugzilla to be told that I should put my site local customizations in the gconf.xml.system tree. That was the first I’d heard of this new Gconf configuration source. Its not in the Gnome manuals which indicate that you should add site local stuff to the gconf.xml.defaults tree. This appears to be a Fedora or Red Hat -ism.

If Red Hat can make new random Gconf configuration sources then so can I. Also, they wont be wiped out by some package upgrade. Here’s how its done.

First I added the following files to my configuration management tool, Bcfg2

  • /etc/gconf/2/path
  • /etc/gconf/2/local-defaults.path

I didn’t modify the contents of the path file but I stored the versions I had for RHEL 5 and RHEL 6. That file references the /etc/gconf/2/local-defaults.path file which is what I was interested in.

In /etc/gconf/2/local-defaults.path I added a new and unique location of my site local configuration source. (Making sure to do so after any reference to includes from the user’s home directory as is present in RHEL 5.) Gconf parses these files from top to bottom. I want to customize the local defaults not prevent the users from changing them.

xml:readonly:/etc/gconf/gconf.xml.ncsu

Next I made sure that directory was created by enforcing its existence with Bcfg2. (If that directory doesn’t exist the following step will create it, but the access permissions will be incorrect rendering it unreadable by users.)

Now I run an Action with Bcfg2 that loads my local customizations into the new Gconf source. Here’s the scriptlet I’m using. (Which references all the XML files I manage that contain Gconf bits.)

for f in `ls /usr/share/realmconfig/data/*.xml`  ; do
/usr/bin/gconftool-2 --direct \
   --config-source xml:readwrite:/etc/gconf/gconf.xml.ncsu \
   --load $f
done

Now I have my own Gconf configuration source that I can completely manage with Bcfg2.

Teaching Bcfg2

Posted on by
Reply

I’ve been putting together a class series for my fellow system administrators at my place of employment.  I need to teach them how to deploy our RHEL 6 and Bcfg2 platform.  The presentations are under the GNU Free Documentation License and if others might find them useful here they are:

Managing Local User Accounts with Bcfg2

Posted on by
Reply

Although I have LDAP managed users and Kerberos authentication, occasionally I need to make local system accounts on my servers.  With the deployment of Bcfg2 on RHEL 6 surely I could do this.  Well, not without some searching.

I came across this:

That turned out to be a fantastic way to examine the local accounts and create them if needed.  You’ll need a “passwd” Probe that’s not mentioned on the pastebin that does nothing more than “cat /etc/passwd”.

Looking closer, you’ll notice that its not using Red Hat style tools.  Fortunately, it was easy to port.  My version is here:

Mostly, I’ve corrected paths and some command options.  I’m also using “–non-unique” which seems strange.  However, I have over 100,000 accounts in LDAP and the LDAP servers limit queries to 500 responses.  I don’t want useradd to attempt to iterate through all the LDAP accounts.

Creating SHA512 Password Hashes

Posted on by
1

Need to generate password hashes?  Perhaps to distribute the hash of the root password to all your machines?  Easy, just whip out openssl.  Until you realize that there is no support for SHA2 password hashes.

I hate re-inventing the wheel, but my searching did not turn up a good way to generate SHA512 password hashes reasonably.  So I wrote a bit of Python to do it.  It will output crypt(), MD5, and SHA512 hashes for a given password.

http://linuxczar.net/code/hashpw.py

This takes advantage of GNU libc extensions, so it may not be uber portable.  Also, I had to write my own salt generation method.  It provides 8 character random salts but could be better.

All semi-modern Linux distributions support SHA512 password hashes now.  Red Hat has backported the support to RHEL 4.7 and RHEL 5.3.  So any reasonably updated RHEL/CentOS machine will work.

OpenAFS 1.4.14

Posted on by
Reply

A couple CVEs about OpenAFS came across my radar today.

  • CVE-2011-0430
  • CVE-2011-0431

Both site OpenAFS 1.4.14 as affected.  However, the OpenAFS community has confirmed that the security issues were fixed in 1.4.14.  Expect an official announcement from the OpenAFS folks soon to confirm this.

RRDTool Backups

Posted on by
Reply

I use RRDTool quite a bit in some of my code.  Not to mention its heavy use in other open source projects.  But backing up my RRD files was a pain.  I can’t keep them in our network filesystem (OpenAFS) that has regular backups because the database files become corrupt.  I can’t move the files from one machine to another because they are very platform/architecture specific. Further, I’ve got a whole directory tree full of RRD files.

I wanted a tool that would scan a directory tree full of RRDs, create a mirror image of that tree elsewhere, and dump out the RRD files to XML.  So, each rlmtools/global/foo.rra file gets dumped out to /tmp/test/rlmtools/global/foo.xml.

So, I wrote it

The first argument is the directory tree to copy, the next argument is where to root the newly created tree.  A -b or -r argument is required for backup or restore mode, respectively.

In a similar vein I wrote a bash script that wraps the above for use with cron.  The srcipt runs the above script, tars and compresses the output, and places the file (with a date in the file name) at a specifc directory.  That directory is then pruned so that all backups are no older than about 2 weeks.

Programming Kerberos 5

Posted on by
Reply

The Kerberos 5 protocol is a beautiful thing, and not too horribly difficult to figure out.  However, using the Kerberos 5 APIs in your code is another matter.  Documentation is sparse and figuring out what logical steps need to happen with the API to get to your end goal isn’t very clear.  At least, its always frustrated me.

The below is an example C program that asks for a username and password and authenticates them against your KDC.  You’ll need a correctly configured /etc/krb5.conf, of course.  The logical steps here are 1) setup your kerberos context, 2) parse the username into a principal, and 3) obtain the initial TGT for that principal.

Comments?  Would you like to help improve the example?

Grubby Fatal Errors, Templates, and Bugs

Posted on by
Reply

I’ve run the grubby tool in Red Hat Kickstart %post scripts for years.  So when it stopped working I filed a bug. Only to be told that if I’m going to run grubby from a %post that I need to setup the environment for it.  I’m annoyed that this couldn’t have been better communicated.  Perhaps in the release notes.

In any case, do you see the following error from grubby?

grubby fatal error: unable to find a suitable template

If so, you’ll need to add something like the following in your %post before any grubby command:

ln -s `awk '{ if ($2 == "/") print $1; }' /etc/fstab` /dev/root

There are cases where that doesn’t work like when using UID=foo to identify the partition to mount.  But it my case, this has solved the problem for me.

Rebooting Isn’t Learning

Posted on by
1

Every time I fix a problem by rebooting (rather than knowing the real cause and fixing it) I feel a little bit of me dies inside. It hurts our industry and our profession when we develop bad habits like guessing instead of knowing. — Tom Limoncelli

Tom Limoncelli is definitely one of my IT Heros.  A recent post on his blog I thought was exceptionally good at teaching you something, and telling of the state of our industry.