[K12OSN] Moving the primary LDAP/PDC functions
John Lucas
mrjohnlucas at gmail.com
Fri Oct 12 23:36:33 UTC 2007
Below are my notes on getting the smbldap-installer scripts to work on
K12LTSP-5EL (CentOS5). They might be helpful:
============================================================================
All testing was done using K12LTSP-5EL (based on CentOS 5) and
smbldap-installer script v3.1.1. The server was a virtual machine running
under VMWare Server v1.0.2. The client tested was an Intel Mac Mini with 512MB
of RAM and Mac OS X 10.4.10. All commands are performed as root, and the LDAP
manager password must be known. The "smbldap-installer" scripts referred to
are by Matt Oquist and David Trask (http://majen.net/smbldap/)
1. Once authentication is switched to LDAP, system boot hangs when the "system
message bus" attempts to initialize. This seems to be related to authorization
being required prior to LDAP being launched. The fix is to delay loading the
"messagebus" service until *after* LDAP loads. This is most easily
accomplished thus:
chkconfig --level 35 messagebus on
chkconfig --level 24 messagebus off
cd /etc/rc.d/rc5.d ; mv S22messagebus S28messagebus
cd /etc/rc.d/rc3.d ; mv S22messagebus S28messagebus
The "ldap" service is S27.
*WARNING* You need to make sure that messagebus is "on" (with chkconfig)
*before* any manual changes (like renaming) are performed, since chkconfig
will set it back to the default start order (S22) *every time* it is run.
Running chkconfig to change the runtime status of messagbus will require
renaming the links again.
2. As many of the smbldap-installer dependancies were pre-installed manually
(actually I created a simple script) prior to running the script to avoid
version conflicts that would prevent the script from completing successfully.
Make certain that your "/etc/yum.reposd.d/k12ltsp-rpmforge.repo" is enabled
*before* running the "smbldap-prep.sh" script, since most of what is needed is
in that repository.
I used "smbldap-configure" instead of "./smbldap all". This was done because
the latest version of CentOS automatically supported by the script is 4.4, in
future this step may not be needed. A list of pre-installed packages (from the
yum log) is in Appendix A.
2a. After running "smbldap-configure" I discovered that the LDAP tree was
missing a vital object. To correct this bug, I manually created an LDIF file
with the needed object (NextFreeUnixId) and added it with the commands:
service ldap restart
ldapadd -x -W -D "cn=Manager,dc=ascs,dc=net" -f fix-ldap.ldif
You will be prompted for the LDAP password that you used during the
"smbldap-configure" step. The object is required to record and supply the the
next "uid" and "gid" numbers when creating new users and groups. The values
are incremented and stored in the object. Without fixing the LDAP tree, no
new users or groups can be created. A sample LDIF file with the object is
listed in Appendix B. The sample will need to be edited to match your domain.
3. It is important to realize that "local" users on both server and client do
not appear in the LDAP tree and that means that you can have duplicate user
names (local and net users), causing confusion. Better would be to limit local
accounts to special administrative users only; people should be in LDAP.
4. Basic authentication of net users on the Mac client works great and the
user's home directory is automatically created on first login. Network users
(LDAP) have their home directories in "/home", while local Mac users are under
"/Users". It's a good idea to keep the net users separate from local users.
Later /home will become and NFS filesystem mount point (I hope). Create the
"/home" directory on the Mac before letting net users login.
5. Groups defined in LDAP are recognized by the Mac. By default groups are
LDAP "posixGroup" objects.
6. It is important when creating groups (on the LDAP server) to use the "-a"
flag to "smbldap-groupadd" to allow the same groups to be used by Samba, and
therefore Windows domain clients. This is also useful for Mac users, since
this allows them to access their home directories on the Samba/LDAP server so
they can backup their files.
7. The biggest surprise was discovering that Mac OS X treats all directories
as if the group "sticky bit" were set: files created in a directory inherit
group ownership from their parent directory. I feel uneasy about this behavior
since it is counter to all my Unix/Linux experience. For this reason, I
created a unique group ("scholars") in LDAP to "own" the /home directory on
the Mac:
mkdir /home
chgrp scholars /home
chmod 1777 /home
It makes me feel better to see directories owned by the unprivleged "scholars"
instead of the privleged "admin" (the default). It may not make any real
difference, but I don't claim to be perfectly rational. The groups assigned to
the users in LDAP *are* valid and read/write/execute privleges are determined
by them, but by default group ownership is inherited from the parent
directory. BTW this is true of local Mac users too.
If/when the /home partition is mounted via NFS from the smbldap server, all
permissions should come set up correctly from the Linux server already created
and ready to go.
8. SSL can be used with LDAP *if* slapd.conf has valid certificates installed.
It is important to *not* disable clear text passwords; they are protected in
an encrypted SSL tunnel.
8a. A side effect of running the "smbldap-configure" script is that it
generates a certificate/key pair for the "slapd" daemon. There are several
steps to turn on TLS/SSL for LDAP: change permissions and ownership of two
files, and edit the /etc/openldap/slapd.conf file. Both the certificate and
key files have to be readable by the user "ldap", the certificate needs to be
world readable. The files needed are in /etc/pkt/tls/certs. Here are the steps
needed to prepare TLS/SSL:
mkdir /etc/openldap/certs
cd /etc/pki/tls/certs
cp ca-bundle.crt /etc/openldap/certs
cp slapd.pem /etc/openldap/certs
cd /etc/openldap/certs
chmod 444 ca-bundle.crt
At this point, I used the "jstar" text editor to split "slapd.pem" into two
separate files, one containing the key (slapd-key.pem) and one containing the
certificate (slapd-cert.pem) using the block-write commands. This was done so
that the proper permissions could be used. After creating the two files I
performed the following steps:
chmod 400 slapd-key.pem
chmod 444 slapd-cert.pem
rm slapd.pem
chown -R ldap:ldap /etc/openldap/certs
Now edit the /etc/openldap/slapd.conf file and change the three "TLS" paths to
look like this:
TLSCACertificateFile /etc/openldap/certs/ca-bundle.crt
TLSCertificateFile /etc/openldap/certs/slapd-cert.pem
TLSCertificateKeyFile /etc/openldap/certs/slapd-key.pem
Then restart the ldap service:
service ldap restart
Now SSL can be used on LDAP transport.
9. Functional groups (e.g. "teachers" and "students" etc.) should be assigned
at account creation time (on the LDAP server). The default group for smbldap
is "Domain Users" for everyone. To ease correct account creation, I will
write some simple "wrappers" for the smbldap commands to standardize the
accounts. One wrapper for each functional group is probably the right
approach. I have been using something like:
smbldap-useradd -a -m -P -c "John Lucas" -g teachers jlucas
It would be nice to populate the "givenName", "sn" and "cn" LDAP attributes in
order to make a better "white pages". So I am thinking of creating a wrapper
that takes the firstname and lastname and ID as arguments and does something
like
this:
smbldap-useradd -a -m -P -N John -S Lucas -c "John Lucas" -g teachers jlucas
10. In order to have all this great stuff work, you need to configure the two
directory services (LDAP and SMB) on each Mac workstation. This is done with
the "Directory Access" utility on each Mac. Add the LDAP server as a new
ldapv3 directory, making sure to enable clear text passwords in the security
section and enable SSL for transport encryption; these changes are made in the
"Security" section.
It is useful to allow SMB/CIFS access too. This enables the user to connect to
her server-based "home" folder and copy to/from the local workstation's home
folder for backup and mobility reasons, when not mounting /home from the
server on the workstation. This is also done in the "Directory Access" utility
and configuring the "SMB/CIFS" entry and adding the domain name and the
address of the WINS server (the smbldap server). Home folders are not
automatically connected, but are available from the "Network" icon in the
Finder sidebar.
Appendix A: Yum log listing of pre-installed dependancy packages
Apr 25 10:33:51 Installed: perl-Net-SSLeay.i386 1.30-4.fc6
Apr 25 10:33:52 Installed: perl-IO-Socket-SSL.noarch 1.01-1.fc6
Apr 25 10:34:08 Installed: libtool-ltdl.i386 1.5.22-6.1
Apr 25 10:34:09 Installed: perl-XML-NamespaceSupport.noarch 1.09-1.2.1
Apr 25 10:34:10 Installed: perl-XML-SAX.noarch 0.14-5
Apr 25 10:34:11 Installed: perl-Convert-ASN1.noarch 0.20-1.1
Apr 25 10:34:12 Installed: perl-HTML-Tagset.noarch 3.10-2.1.1
Apr 25 10:34:13 Installed: perl-HTML-Parser.i386 3.55-1.fc6
Apr 25 10:34:14 Installed: perl-Compress-Zlib.i386 1.42-1.fc6
Apr 25 10:34:17 Installed: perl-libwww-perl.noarch 5.805-1.1.1
Apr 25 10:34:36 Installed: samba.i386 3.0.23c-2.el5.2
Apr 25 10:34:37 Installed: perl-Crypt-SSLeay.i386 0.51-11.el5
Apr 25 10:34:45 Installed: openldap-servers.i386 2.3.27-5
Apr 25 10:34:46 Installed: openldap-clients.i386 2.3.27-5
Apr 25 10:34:49 Installed: perl-LDAP.noarch 1:0.33-3.fc6
Apr 25 10:34:49 Installed: perl-Digest-SHA1.i386 2.11-1.2.1
Apr 25 11:14:26 Installed: perl-Digest-HMAC.noarch 1.01-15
Apr 25 11:14:27 Installed: perl-GSSAPI.i386 0.23-1.el5.rf
Apr 25 11:14:28 Installed: perl-Authen-SASL.noarch 2.10-1.el5.rf
Apr 25 11:14:30 Installed: perl-Net-LDAP.noarch 0.3202-1.2.el5.rf
Apr 25 11:15:06 Installed: smbldap-tools.noarch 0.9.1-1.2.el5.rf
Appendix B Listing of "fix-ldap.ldif"
dn: cn=NextFreeUnixId,dc=ascs,dc=net
objectClass: inetOrgPerson
objectClass: sambaUnixIdPool
cn: NextFreeUnixId
sn: NextFreeUnixId
gidNumber: 10001
uidNumber: 10001
===========================================================================
On Friday 12 October 2007 19:06, David Hopkins wrote:
> I have been trying to figure out how to move the primary LDAP/PDC server to
> a system which only acts as the LDAP/SMB PDC. My biggest concern is that I
> will have to rejoin all the Windows machines to the domain, and also have
> other DOMAIN related issues.
>
> What I have tried is to use the smbldap-installer scripts. Since I am
> using CentOS5, the script doesn't quite work for installing the correct
> rpms. It uses the dag repositories. However, I removed the dag rpms and
> replaced them with rpmforge rpms for those packages. At that point, I had
> all the required packages installed. Then, I used net getlocalsid on the
> existing LDAP/PDC to get the DOMAIN sid. I then used net setlocalsid on
> the system that is to become the new PDC. Finally, I ran smbldap-configure
> to enter the rest of the information. In particular, I gave the new system
> the same DOMAIN information.
>
> I have run slapcat on the existing LDAP server with the intent of importing
> everything to the new server, but I have duplicate entries. If I delete the
> ldif entries from the slapcat'ed file that are the same as what the
> smbldap-installer script created and then sladadd what is left, this should
> leave me with a new system that can act as the new LDAP/SMB PDC. I checked
> the DOMAIN ldif info and it looks the same. I tested with one account, and
> I can log in on Linux with it. Without activating smb though, I can't
> verify the Windows login.
>
> So, before I do this, I wanted to ask the list if they see anything wrong
> with this approach, or is there a simpler approach? For instance, I have a
> slave ldap server running as well. Is it possible to just make the slave
> become the master, and also make it the PDC server as well? In this case,
> moving the ldap/pdc is just creating a slave replica and promoting it. I
> haven't seen any notes on how to do this though.
>
> Sincerely,
> Dave Hopkins
--
"History doesn't repeat itself; at best it rhymes."
- Mark Twain
| John Lucas MrJohnLucas at gmail.com |
| St. Thomas, VI 00802 http://mrjohnlucas.googlepages.com/ |
| 18.3°N, 65°W AST (UTC-4) |
More information about the K12OSN
mailing list