Attachment 196061 Details for Bug 291401 – Installation notes

Installation notes

blah.txt (text/plain), 7.38 KB, created by Dominic Lepiane on 2007-09-14 18:16:05 UTC

(hide)

Description:

Filename:

MIME Type:

Creator: Dominic Lepiane

Created: 2007-09-14 18:16:05 UTC

Size: 7.38 KB

patch

obsolete

>Active Directory and UNIX
>
>The UNIX-like systems, RedHat Linux based systems in our case, can use Active Directory to store user information instead of a stand-alone NIS server. This page describes the process of having set up AD and RHEL to talk to each other as well as instructions on enabling UNIX integration for a user's account.
>Configuring UNIX Accounts
>
>   1. Connect to ESMOND (this is where the "NIS Server" component has been installed)
>   2. Open Admin Tools -> AD Users and Computers
>   3. Find the user you wish to create a UNIX account for,
>   4. Go to Properties,
>   5. Go to UNIX Attributes tab.
>
>Now the fun begins!
>
>   1. Choose the NIS domain from the drop-down (pointgrey)
>   2. Set the correct UID (if duplicating an existing account)
>   3. Set Login Shell to /bin/bash (or whatever the UNIX prefers)
>   4. Verify Home Directory is correct
>   5. Set primary group to unixusers
>
>Notes on Universal Private Groups (UPG)
>
>RedHat (and many other GNU/Linux systems) make the user's primary group that happens to be a) named the same as the user, b) the same group number as user number, and c) does not have any other members. This is security practice of some (dubious) benefit... In Micrsoft AD, however, you don't have to worry about this because you can't create UPGs. Aparently groups in different OUs from users have naming conflicts.
>Creating Groups
>
>   1. In Admin Tools -> AD Users and Computers, find the UNIX Groups OU,
>   2. When creating a UPG, go in the UPG OU,
>   3. Right-click the OU and choose New -> Group,
>   4. Fill out the name of the group (lower-case, please) and finish the Wizard,
>   5. Right-click on the new group and go to Properties -> UNIX Attributes,
>   6. Choose the NIS Domain from the drop-down (pointgrey),
>   7. Set the group ID (if matching an existing UNIX group),
>
>Setting Up Active Directory
>
>The guide from Scott Lowe is the main source of the instructions below.
>Linux-AD Integration
>
>Basically AD is comprised of two parts: Kerberos for authentication and LDAP for account information. Microsoft uses a modified MIT Kerberos service and a fairly normal LDAP service so GNU/Linux (or other UNIX-like and UNIX systems) authenticate against the kerberos service and get account information from the LDAP directory. In this guide, we use Samba to help automate the process along the way.
>Enable Editing/Display of UNIX Attributes
>
>There is a "partially RFC 2307-compliant schema" installed with Windows Server 2003 R2 which includes UNIX-specific attributes such as uid, gid, login shell, etc. However, these attributes are not exactly accessible so the easiest way to enable the editing of these attributes is to install the Server for NIS component on at least one domain controller:
>
>Installing Server for NIS
>
>In Point Grey's case, this has been installed on Esmond. I have not installed this on Rosser since, apparently, there's no "Active Directory Components" available on Rosser.
>
>This causes a new tab, labeled UNIX Attributes, to appear in the properties dialog box for users and groups.
>Create an LDAP Bind Account
>
>To search the directory for user information, AD by default, does not allow anonymous reads. So a user has been created that has no special privileges but can bind to the directory thus allowing read access. The user is called "Read Only" and is in the password file in project\admin\doc.
>
>Since this user's credentials are going in the ldap.conf of all the servers, one thing to note is that this user is not allowed to change password and the password never expires. This will protect the account from harm.
>The "Catch"
>
>The catch is that AD for some reason does not allow read of our new-found UNIX attributes (uidNumber, gidNumber, homedir, shell) which prevents the read only user (and everyone else) from pulling that information. So to correct this, read permissions on the domain have to be (re)granted:
>
>   1. Run AD Users and Computers as a domain admin,
>   2. Right-click the top-level of the domain (the pointgrey.local part),
>   3. Choose "Delegate Control...",
>   4. Go through the wizard granting at least "Read all user information" to the user (I granted read user info to allusers).
>
>Configure UNIX attributes
>
>... See "Configuring UNIX accounts" above.
>Setting Up RHEL
>
>These steps are also taken from Scott Lowe above.
>Talk LDAP
>
>The server will need the various LDAP libraries... These are stock on recent distros so I'm not exactly sure what we need, but "ldaputils" is a good start.
>
>In RHEL, authentication configuration is partially managed by "authconfig" which is both a command line and GTK utility. It allows you to manage the "big picture" items of the auth setup, but none of the fine-grained stuff we need for AD integration. The steps for authconfig given here can all be done through the GTK version.
>Run authconfig
>
>   1. authconfig --updateall (this will stomp any quirks in the various config files)
>   2. authconfig --udpate --enableldap --enableldapauth --ldapserver=rosser.pointgrey.local --ldapbasedn="DC=pointgrey,DC=local" --disableldaptls --enablecache --enablelocauthorize
>
>The "--update" option, as opposed to --test, sets all the given parameters, each parameter can be run individually. The "enableldap" puts ldap in /etc/nsswitch.conf, enableldapauth puts ldap in pam.d/system-auth. The other ldap options set the LDAP server, the base DN, and disable TLS (not supported by AD). The "enablecache" option turns on nscd (a good thing) and the "enablelocalauthorize" allows accounts in the local passwd file to authenticate in addition to the LDAP accounts (e.g. root).
>
>All this can be done manually, but that's not The RedHat Way. If you don't run authconfig to do these steps, if authconfig is run later, it may stomp all (or some) of these changes.
>Tune LDAP to work with AD
>
>Finish the setup in /etc/ldap.conf:
>
>    * ldap_version 3
>    * binddn "CN=Read Only,CN=Users,DC=pointgrey,DC=local"
>    * bindpw as per password file
>    * scope sub
>    *
>
>      Enable the RFC 2307 (AD) mappings:
>          o nss_map_objectclass posixAccount user
>          o nss_map_objectclass shadowAccount user
>          o nss_map_attribute uid sAMAccountName
>          o nss_map_attribute homeDirectory unixHomeDirectory
>          o nss_map_attribute shadowLastChange pwdLastSet
>          o nss_map_objectclass posixGroup group
>          o nss_map_attribute uniqueMember msSFU30PosixMember
>          o pam_login_attribute sAMAccountName
>          o pam_filter objectclass=User
>
>And restart nscd and you should be done!
>
>Note we did not go the kerberized authentication route, rather just authenticate against the LDAP directory directly. Kerberos requires joining the domain, kerberizing hosts and services, etc. It is not required for simple user auth.
>
>Try querying the directory server:
>
>    * ldapsearch -x -D "CN=Read Only,CN=Users,DC=pointgrey,DC=local" -W
>
>This will spew the whole directory (that you have read permissions on, not passwords)
>
>    * ldapsearch -x -D "CN=Read Only,CN=Users,DC=pointgrey,DC=local" -W '(cn=Dominic Lepaine)' uid
>
>Returns Dominic's uid (dominicl)
>
>    * PgrWiki
>          o HomePage
>          o RecentChanges
>    * Editing
>          o Edit this page
>    * Information
>          o Last edited on September 13, 2007.
>          o PageHistory
>          o PageInfo
>          o DebugInfo
>    * Search
>          o
>          o
>          o LikePages
>    * User info
>          o
>

Actions: View

Attachments on bug 291401: 196061