[K12OSN] Moving the primary LDAP/PDC functions

Craig White craig at tobyhouse.com
Fri Oct 12 23:53:44 UTC 2007


On Fri, 2007-10-12 at 19:36 -0400, John Lucas wrote:
> 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
----
moving the messagebus links is messy and bad form.

you could solve the issue much more simply by adding
to /etc/ldap.conf...

timelimit 30
bind_timelimit 30
bind_policy soft
nss_initgroups_ignoreusers root,ldap
----
> 
> 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)                         |
> 
> _______________________________________________
> K12OSN mailing list
> K12OSN at redhat.com
> https://www.redhat.com/mailman/listinfo/k12osn
> For more info see <http://www.k12os.org>
-- 
Craig White <craig at tobyhouse.com>




More information about the K12OSN mailing list