Removing Generic Logins

Sunday, March 18 2007 @ 10:36 pm MDT

Contributed by: MacTroll

Keeping things compliant and flexible.

As you navigate your way through policy compliance and client management best practices you'll be constantly motivated to remove any generic logins to both your client systems and servers. Don't fight this urge. With keeping a few things in mind, you're quite able to limit all administration activities to individual user accounts.

We've got a few articles on this already, but we figured it would be a good idea to tie all of them together to show you how they all fit.

Read on for how to do this...

First we're going to split things up between Open Directory administrators and local system administrators. In 10.4 there's a clear delineation between local admins and OD, or network, admins. Local admins can manage the local machines and use Server Admin on the servers. They can authenticate through any dialog boxes requiring administrative rights. Network admins can create users in Open Directory, change the passwords for those users and perform all of the functions in Workgroup Manager as long as they are working in the network domain. However, contrary to popular belief, a network admin is unable to do such things as authenticate to the local machine to change settings in the system preferences.

This is different from OS X 10.3 where an admin was an admin was an admin. Since this change took a lot of admins by surprise there was a tendency to either create a local generic admin account on the client machines that all "admins" knew. Or to double up users with both a local admin account and a network admin account. Sometimes these went by the same shortname which further increased the confusion.

With 10.4 you don't really need to do any of this, and in fact you should really spend some time undoing the damage that you may have inadvertently caused before. Ideally you want to remove all accounts which more than one person knows the password for, and allow admin users to use their normal day-to-day account for all of their duties. Additionally you'll want to add granularity to your client machine configuration such that not everyone is an admin on all machines.

OD Admins

When instantiating an Open Directory domain you will be asked to create a "diradmin" user to be the top dog of that domain. This was more convoluted in OS X Server 10.3 when the admin user shared the same short name as a local admin. Even in 10.4, however, there is a pretty black and white delineation between admins and non-admins.

If you make a user an admin they pretty much have the run of Open Directory, although there is some sneakiness you can engage in to limit them as we'll explain later.

Password Server Admins

While you don't have any options to do this through the GUI, you can easily use pwpolicy to allow, or disallow, users to be password server admins. By default all OD admins are PWS admins. This means that they are able to change the password for any user in the password server. Through the use of the pwpolicy command you are able to toggle the PWS admin status for individual users. For example, you could demote an OD admin to not be a PWS admin. This would allow that admin to manage policies on a uses through MCX and change anything about their account, but not change their password.

Much more common, and useful, is the promotion of a non-admin user to being a PWS admin, but not an OD admin. For example, you may have helpdesk staff that need the ability to reset a user's password, but you don't want them to be able to change anything else about a user. Be careful with this setup though, as that non-admin user would be able to reset any OD user's password, including any OD admins.

A more secure way of handling the need for password resets would be to create a script, probably presented to the users as a webpage, that would allow a non-admin to change passwords only for non-admin users. I believe some of those among us have ginned something up along these lines. If you have we'd love for you to share.

Directory ACLs

If you want to get really clever you could lock down individual admins to only making changes in certain parts of your directory. OS X 10.4 has the beginnings of this in place in the form of Directory Access Controls (DACs). You can read more about this here, but it's not really for the faint of heart. Plus, all of the GUI tools from Apple seem to only work if the user is also a member of a group in the directory with a GID of 80. This happens to be the admin group and kind of kills your plans for making administrators more granular. You would have to write your own tools/scripts to do the directory work that you want if you enable the DACs.

Local Admins

So lets move on to the local systems. While this is fairly straightforward, it's ideally something that you knew about before you created your image and rolled it out to all of your machines, however.

You'll want to create a group within OD, or whatever directory service you're using, that will contain the users that you want to have local admin access to a collection of machines. Call this group "local_admins" or something. Now nest this group within the local group.

You can do this via the GUI by using Workgroup Manager targeted against the local machine. When you nest the directory service group you'll be asked to upgrade the group from a legacy group. If you don't do this, you can't nest, so go ahead and do it.

You can also set this up from the command line if you would like. The first command upgrades the group record format, the second adds in the group "local_admins".

	dseditgroup -o edit -f n -t group -n /NetInfo/DefaultLocalNode admin
	dseditgroup -o edit -a local_admins -t group -n /NetInfo/DefaultLocalNode admin

Now anyone in the "local_admins" group can authenticate through the GUI admin dialogs and, as of 10.4.9, use sudo on the command line. You should even be perfectly free to remove the local admin account altogether. Some admins have hesitations about doing this, as a failure of directory services would prevent any admin activities on the box.

We have an earlier article on this.

Changes with 10.4.9

Prior to 10.4.9 any network admin could use sudo on the local box, even though they would not be able to authenticate to any GUI dialogs requiring an admin account. This was because sudo was not using the new group membership APIs which allow an application to differentiate between the local admin group and the network admin group. This caught more than a few people off guard and caused some rethinking of how to configure admin abilities.

So why is this anyway?

It's not crazy to ask why the change from the 10.3 behavior. Many organizations had built their management workflow around one admin group and were happy for the simplicity. The simplicity was based on a foundation of sand, though, as allowing any group that had the group id of 80 on the network be an admin could seriously compromise your machines. A rogue DHCP server pushing out a bad LDAP domain to machines configured to trust DHCP for that information could easily own your system. Even if DHCP hadn't been coopted, a simple hijacking of DNS would point your client machines to a different LDAP server and the would be lambs for the slaughter.

On the functionality side, you can now bifurcate network and local admins. The dean of the college can truly be the master of her own system without having to worry about a BOFH rooting her machine just because they got hired to the network admin team.

Additionally you can now have groups of machines easily managed by different groups of admins. Machines in a graphics department can only be administered by members of a graphics admin group, for example, whereas machines in the finance department only by members of the finance help staff.

What to do with the local admin?

This is a good question, and one that different places have handled in much different ways. In some extreme cases organizations have completely removed all local admin accounts, period. While I don't imagine Apple tests for this scenario I have heard anecdotally that things seem fine running in this mode. If the network is unavailable, they just re-image the machine as these are typically lab machines and they have no desire to individually troubleshoot issues.

Other sites have the CIO, or other potentate, set the initial admin password and only that person knows. The password is then put inside a sealed envelope and put in a safe. This way there is access to it, however, it will be logged in accordance with whatever auditing procedures you have. This gives you a tiny bit of a backdoor, but one that you'll probably never really have any need for.

I've also seen some places randomize the password and leave the local admin. If you look at the admin's shadow hash file, you can randomize the characters that are already in there. Since it's a one-way hash, you have no real earthly way of knowing what the password actually is. If you want to go for the more dramatic you can have multiple members of your IT staff each type a few characters of the password as your setting up your golden master image. This gives the whole process a bit of a nuclear launch code feel.

Apple Remote Desktop

Another item to throw in here is Apple Remote Desktop. Most organizations have created a local admin account on their machines that they use for ARD. This ends up being a generic account and something you'd rather get rid of. ARD can use directory groups to manage authentication to the local clients. More on this in our previous article on the subject.

Comments (4)

AFP548
http://www.afp548.com/article.php?story=20070318213652764