[Network Administration]: Network Accounts

At a basic level, the Kerberos KDC manages the passwords, and the LDAP directory is used to manage user accounts and user groups for both Linux systems and OSX systems. In order to do this, the Kerberos KDC needs to have users and passwords, and the directory needs entries with some basic information that both systems require for authorization. Once the information is in both the KDC and the directory, then both linux and OSX systems can be configured to use the information.

User and Group attributes
Users need to be added to the Kerberos database. We’ve already added a user, called user1 to our Kerberos database previously. The user and it’s primary group also need to be added to the LDAP directory. We’ll take a more detailed look at what attributes are needed for basic user authorization and how they are used.
Groups
Managing group information is pretty basic, and really just needs the list of user accounts that belong to the group, and the group ID number.

# group1, groups, example.com
dn: cn=group1,ou=groups,dc=example,dc=com
objectClass: posixGroup
objectClass: apple-group
cn: group1
description: Users Group
memberUid: user1
gidNumber: 20000

The group uses the posixGroup objectClass. This is the expected class for group entries for Linux systems and for OSX authorization to an LDAP directory. For our OSX systems this is extended with the apple-group objectClass to allow some extra attributes to be used for the entry. This entry has basic information for a user group. The group is called “group1” (the ‘cn‘ attribute), has a group ID number of 20000, and has one user called ‘user1’. It maps onto an entry in the standard unix /etc/group file as:

<cn - group name>:<not used here - (password)>:<gidNumber>:<memberUid list>

See the group man page for more information on the fields.

OSX can also map it’s group records onto these attributes. The records that we’ll use for OSX (and the mapping to the directory attributes) are:

    OSX Mapping

  • Comment -> description
  • CreationTimestamp -> createTimestamp
  • GroupMembership -> memberUid
  • Member -> memberUid
  • ModificationTimestamp -> modifyTimestamp
  • NestedGroups -> apple-group-nestedgroup
  • PrimaryGroupID -> gidNumber
  • RecordName -> cn

This mapping follows the built in RFC2307 mapping that OSX supports for groups. There is an added record supporting nested groups called NestedGroups, and both records GroupMembership and Member map onto the same LDAP attribute memberUid. This mapping is taken from the Open Directory Administration Guide for OSX v10.6 from Apple.
User Accounts
User accounts are more complex because Linux and OSX don’t use entirely the same information for both, but a lot of it can be reused for both systems.

dn: uid=user1,ou=users,dc=foodclaw,dc=net
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
objectClass: apple-user
uid: user1
givenName: First
sn: User
displayName: User1
cn: First User
uidNumber: 20000
gidNumber: 20000
loginShell: /bin/tcsh
homeDirectory: /home/user1
description: User Account
description: First User
authAuthority: ;Kerberosv5;;user1@EXAMPLE.COM;EXAMPLE.COM;
apple-user-homeurl: <home_dir><url>nfs://home-filer/accounts/</url><path>user1</path></home_dir>
shadowExpire: -1
shadowFlag: 0
shadowWarning: 7
shadowMin: 8
shadowMax:999999

The user entries use the posixAccount objectClass, and entries for OSX extend this with the apple-user objectClass to allow for some extra attributes that we’ll use.
Going through the user entry, the user ID (the ‘uid‘ attribute) for the user is ‘user1’. There is also some basic naming information such as the users real first name (the ‘givenName‘ attribute), the last, or surname (the ‘sn‘ attribute), the full users name (the canonical or ‘cn‘ attribute) which I’ve constructed from the first and last name. There is also an attribute called the ‘displayName‘ which OSX can use for it’s separate record of a nickname. This one is not really needed, and OSX can map this onto another attribute such as ‘givenName‘. The entry also contains the user’s ID number (the ‘uidNumber‘), the primary group ID number (the ‘gidNumber‘), and the login shell (the ‘loginShell‘). There are two entries for the home directory, the first is ‘homeDirectory‘ which is what the Linux systems use. OSX also uses this attribute, but uses this as the local path to the home directory. OSX also uses a second attribute called ‘apple-user-homeurl‘ which is a URL description of how to get to the home directory if it’s not on the local file system. OSX also will need this for other things that we want it to do later. OSX also uses an authAuthority attribute. Lastly, there are some shadow account attributes.
These attributes map onto an entry in the standard unix /etc/passwd file as:

<uid - username>:<not used here - (password stored in the Kerberos database)>:<uidNumber - numerical user ID>:<gidNumber - primary numerical group ID>:<cn>:<home directory>:<login shell>

See the passwd man page for more information on these fields. In addition, the attributes also map onto an entry in the standard unix /etc/shadow file as:

<uid - username>:<not used here - (password stored in the Kerberos database)>:<shadowLastChange (no change in password yet, so not present) - last passwd change>:<shadowMin - Minimum number of days between password changes>:<shadowMax - Maximum days the password is valid>:<shadowWarning - Number of days to warn for password changes>:<shadowInactive - Number of days that the password expires that the account is disabled>:<shadowExpire - absolute date that the account expires>

See the shadow man page for more information on these fields.

OSX can also map it’s user records onto these attributes. The records that we’ll use for OSX (and the mapping to the directory attributes are):

    OSX Mapping

  • AuthenticationAuthority -> authAuthority
  • Change -> shadowLastChange
  • Comment -> description
  • CreationTimestamp -> createTimestamp
  • Expire -> shadowExpire
  • FirstName -> givenName
  • GeneratedUID -> uidNumber
  • HomeDirectory -> apple-user-homeurl
  • LastName -> sn
  • ModificationTimestamp -> modifyTimestamp
  • NFSHomeDirectory -> homeDirectory
  • PrimaryGroupID -> gidNumber
  • RealName -> cn
  • RecordName -> uid
  • UniqueID -> uidNumber
  • UserShell -> loginShell

This mapping also follows OSX’s mapping for RFC2307 users. There are some additional records – AuthenticationAuthority, FirstName, GeneratedUID, HomeDirectory, and LastName. This mapping is taken from the Open Directory Administration Guide for OSX v10.6 from Apple. The attribute sn needs to be assigned by the schema, so I’ve added givenName also and the OSX native records that map to it.
The record AuthenticationAuthority defines how the user is to be authenticated by OSX. When a user requests to be authenticated, this attribute is read from the directory. If the record does not exist or is set to “basic“, then it will attempt to bind as the user against the directory to authenticate the user. If this is set to “Kerberosv5“, then it will attempt to authenticate the user against the KDC. How the values are interpreted is specified in the Open Directory Authentication section of the Open Directory Administration Guide and in the Open Directory Programming Guide. The value that we use for Kerberos authentication is

;Kerberosv5;;user1@EXAMPLE.COM;EXAMPLE.COM;

The first field specifies to use Kerberos to authenticate – “Kerberosv5“. The next field is left empty. The third field – “user1@EXAMPLE.COM” – is the principal and the Kerberos realm. The last defined field – “EXAMPLE.COM” – is the Kerberos realm. There is technically a field at the end, but that is also left empty. The record GeneratedUID needs to be set for Mountain Lion and up to access the “Users and Groups” pane of the System Preferences. Lastly we define the HomeDirectory record which is used to specify how to access a non-local home directory for the user.

Advertisements

4 thoughts on “[Network Administration]: Network Accounts

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s