[389-users] Developting a CentOS-DS setup
John A. Sullivan III
jsullivan at opensourcedevel.com
Sat Jun 6 23:58:01 UTC 2009
On Sat, 2009-06-06 at 15:53 -0500, Doug Coats wrote:
> I am new to using CentOS-DS and LDAP and I am having difficulty
> finding solid information on setting up using CentOS-DS as the
> information and authentification center of my network.
>
> I have googled a number of different combinations looking for the
> informaiton I need but have not found any good resources to setup what
> I am after. I have downloaded and am going over the Red Hat
> documentation and where it is very informative it certainly is not a
> Howto.
>
> My biggest need for resources is in setting up the authentification of
> different services and LDAP.
>
> I am using CentOS 5.3 and CentOS-DS 8.1. These I have installed and
> running on a test server.
>
> I would like to accomplish the following things in this order.
>
> Linux authentification
> Samba authentification
> Dovecot authentification
>
> So my questions to begin with are: How do I get Linux to use LDAP to
> authenticate instead of the passwd and shadow files?
>
> Once I get that to work: How do I get Linux to to do the normal things
> it does with adduser (like create a home directory, create a group,
> and things I can't think of)?
>
> If anyone could push me in the right direction I would really appreciate it.
<snip>
We are using almost an identical setup except for Dovecot and we started
with DS 8.0 and upgraded to 8.1. I'm afraid I'm up to my eyeballs in a
project so I can't customize this for you but I'll paste in as much of
our internal documentation as would be prudent to do. You will need to
understand the principles behind the steps so you can adapt it
accordingly. For example, we installed the master replica on a vserver
- a great project (www.linux-vserver.org) but it does introduce some
complexity to LDAP. We also use a RO replica on KVM. Both are in an
iSCSI environment. We also sync passwords with Active Directory for
multiple clients - oh, and yes, this is a multi-tenant environment -
hence the unusual hierarchical structure and bizarre ACIs. As I said,
you will need to adapt but hopefully this will get you started. (and I
hope it is not dropped for SPAM because of its length - hmm come to
think of it, I think I'll send this email separately and then send the
same email with all the notes. This way, if it does get trapped as
SPAM, you can fish it out)
I'm sure there are errors in this document and would appreciate
corrections, improvements, and comments from those who really know what
they're doing (unlike me). Names and numbers changed to protect the
innocent and my job!
Create the VServer guest - probably not necessary to you - sorry but the
formatting is being lost - this will be very hard to follow :-(
Clone a new server named ldap1.mycompany.com with IP address
172.x.x.48/24 on the Internal VServer:
vserver ldap1 build -m clone --hostname ldap1.mycompany.com --interface
ethx:172.x.x.48/24 -- --source centos-basevs
Set the proper /tmp file size and an adequate number of file handles for
directory services:
On the VServer HOST do:
cd /etc/vservers/ldap1
Edit fstab by setting the options for the tmpfs mounted on /tmp to:
size=128m,mode=1777,nosuid,nodev,noexec
mkdir /etc/vservers/ldap1/ulimits
echo 65535 > /etc/vservers/ldap1/ulimits/nofile
(otherwise the DS installation will complain about only 1024 file
handles available which may indeed be a problem)
cd
CentOS installations enforce pam_loginuid.so by default. Since it
requires write access to /proc which is not available in the vserver, it
will cause key processes to fail. We this disable it with the following
one-line command:
sed -i -e "s/^session.*required.*pam_loginuid.so/# session\trequired
\tpam_loginuid.so/g" /vservers/ldap1/etc/pam.d/*
Edit the /vservers/ldap1/etc/hosts file so it contains the following two
lines:
127.0.0.1 localhost localhost.localdomain
172.x.x.48 ldap1 ldap1.mycompany.com
Install Directory Server
Start the new VServer guest (vserver ldap1 start) and connect to it
(vserver ldap1 enter).
The rest of these instructions assume one is on the ldap1 console unless
specified otherwise.
Create the ldap group and user
groupadd -g 6xx ldap
useradd -s /sbin/nologin -d /var/lib/dirsrv -g ldap -u 6xx ldap
Edit /etc/yum.repos.d/CentOS-Base.repo by enabling the centosplus
repository and adding the test repository with the following stanza:
[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=0
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
exclude=java-1.7.0-icedtea
Install the directory server:
yum --enablerepo=c5-testing install centos-ds java-1.6.0-openjdk
After centos-ds and its many dependencies have installed, install these
additional packages:
yum install xorg-x11-xauth bitstream-vera-fonts dejavu-lgc-fonts
urw-fonts firefox
Run setup-ds-admin.pl
Enter yes to continue and to accept the license terms
The setup routine will run dsktune and may issue a warning about file
handles or tcp keepalives. Enter yes to continue unless there is a more
serious error.
Choose a custom installation (because we must specify the vserver guest
address)
The default Computer name should be fine (ldap1.mycompany.com)
System user is ldap
System group is ldap
There is no configuration directory server yet
Administrator ID is someone
Password is <password>
Administration domain is mycompany.com
Take the default 389 port for now. We will implement LDAPS later
Directory server identifier is ldap1
Suffix is dc=mycompany,dc=com
Directory Manager DN is cn=Directory Manager
Use the <different password>
Do not install sample entries
We do not want any suggested entries so type none
Take the default administration port
IP address is 172.x.x.48 - NO, now that we have loopback remapping and
Single IP Special Casing, we can leave this blank. NOOOO!!!!! We can't
if we want to use Single IP Special Casing (which we probably do because
we will be setting up lots of connections). This completely destroyed
our setup when we implemented SSL. We did recover using the procedures
outlined in the notes but then reinstalled anyway just in case.
Run Administration Server as ldap
Enter yes to set up the servers
Start the console GUI with (the viewing computer must be running X and
using ssh X forwarding - configured in /etc/ssh/ssh_config). Beware the
idm-console windows open minimized:
centos-idm-console -a http://ldap1.mycompany.com:9830 -s slapd-ldap1
Login using cn=Directory Manager and the associated password
Click on the Configuration tab
Select the top level item in the tree on the left side
(ldap1.mycompany.com:389) and click on the SNMP tab. Fill in the
following details:
Name: ldap1-ds
Description: Directory Server on ldap1
Organization: My Company
Location: Data Center 1
Contact: Operators
Go to the SASL Mapping tab and add a new item with the following
details:
Name: kerberos uid mapping clients
Regular Expression: \(.*\)@\(.*\)\.\(.*\)
Search Base DN: o=Internal,dc=mycompany,dc=com
Search Filter: (uid=\1)
Click on Save
We will need to install the SAMBA schema. Copy the schema from the
SAMBA server (/usr/share/doc/samba-*/LDAP/samba.schema) and download the
schema importer
(http://directory.fedoraproject.org/download/ol-schema-migrate.pl)
Run the importer:
perl ol-schema-migrate.pl -b samba.schema
> /etc/dirsrv/slapd-ldap1/schema/61samba.ldif
Even easier, copy the already created 61samba.ldif file from the test
lab into /etc/dirsrv/slapd-ldap1/schema/
Change ownership and permissions on 61samba.ldif:
chown ldap:ldap 61samba.ldif
chmod 440 61samba.ldif
Restart the directory server (service dirsrv restart)
Return to the idm-console window, the Configuration tab, and click on
the Data object in the left panel
Click on the Passwords tab.
Enable fine grained password policy
User must change after reset - Oops! That's a problem with X2Go. There
is currently no way to change the password on first login via X2Go.
Here is the email explanation from Alex:
SKIP DETAILS - another great project (www.x2go.org)
Keep six passwords
Password expires in 31 days
Warned four days before (to account for long weekends)
Allow 4 login attempts after expiration
Check password syntax to enforce minimum length of 9 characters with 3
character category and a token length of 2 (We need the last two in
order to synchronize with Windows AD)
Click the Account Lockout tab
Enable account lockout after 4 failures with a 10 minute reset. Lock
out for 10 minutes - This is more than three because of X2Go. It
appears to make three logins during the session setup process. Thus, a
single mistyped password locks an account limited to only three failed
attempts. Here is the email explanation from Alex:
SKIP DETAILS
Click on Save
Expand Data, expand dc=mycompany,dc=com, go to the UserRoot database for
dc=mycompany,dc=com. Add the nsroledn attribute. Enable the presence
index for member, nsroledn, owner, seeAlso, and uniquemember. Click
Save.
Expand the Logs item in the left panel. Enable Audit logging allowing 5
logs rotating each week or 100 MB with total storage of 500 MB held for
40 months or delete when space is below 50MB. Click Save. Disable
Access logging. Click Save.
Expand the Plugins item in the left panel
Click on the Referential Integrity plugin and enable it. Click on Save.
Click on the attribute uniqueness plugin, enable it and change the
second argument to o=Internal,dc=mycompany,dc=com. Click on Save.
To this point, we have been working on the Configuration tab. Now click
on the Directory tab.
Left click on the top level item (ldap1.mycompany.com:389). We left
click first because this java implementation does not select
automatically when right clicking. Once the top level item has been
selected with a left click, right click and choose New Root Object and
select dc=mycompany,dc=com. Select dcobject from the ensuing dialog box
and click OK and then OK again.
Expand the config object in the left panel.
Click on plugins
Left click and then right click the attribute uniqueness plugin and
choose copy.
Go to mycompany, left/right click and paste.
Edit the new copy of attribute uniqueness by changing the word attribute
to gidnumber in the name, nsslapd-plugindescription, and entrydn fields,
and the nsslapd-pluginarg0 to gidnumber. Click OK. Left click then
right click the new gidnumber uniqueness entry and copy. Then paste it
back into config / plugins. For some reason, the DS GUI tries to copy
in everything previously copied so ignore the errors about duplicate
objects.
Return to the first copy under mycompany and edit it so name,
description, and entrydn use uidnumber instead of gidnumber, and change
nsslapd-arg0 to uidnumber. Save changes. Right click, copy, and then
paste into config / plugins.
Return to the first copy under ssiservices and edit it so name,
description, and entrydn use cn instead of uidnumber, and change
nsslapd-arg0 to cn. Save changes. Right click, cut, and then paste
into config / plugins.
Restart the directory server (service dirsrv restart or use the
idm-console task tab)
WE DO NOT ALLOW ANONYMOUS BINDS AND MUST ALLOW CLIENTS TO ADMINISTER
THEIR OWN PORTION OF THE TREE SO THIS MAY NOT APPLY TO YOU. PLUS, I
BELIEVE WILD CARDS IN THE GROUPDN DEFINITIONS DID NOT WORK IN 8.0 AND WE
HAVE STILL NOT FIXED OUR ACIS IN RESPONSE. WE HAVE NOT TESTED THIS WTIH
8.1
We need to create a root searcher named uid=searcher,dc=mycompany,dc=com
with a custom password policy that does not require the user to change
the password and does not expire passwords. Create the user with
givenname (or first name)=Directory, sn (or last name)=Searcher,
uid=cn=searcher (all lower case - remember to change the cn). Give it
the medium security password - oops - we do not want to do that as the
password will be recorded in the ldap.conf file on vd1 which is world
readable. Instead, us a password as would be created for a searcher
user by the clientsetup script. See the script for the details. To do
this:
Left and then right click on mycompany in the left panel and choose New
User. Set the fields as above. Save the new user, then left/right
click on the new user, choose Manage Password Policy and then For user.
Enable fine grained passwords on the password tab. Set the password
syntax as above (9 characters, 1 character category, 7 tokens). Click
Save.
Next we must make many adjustments to security. Left/right click on
mycompany and choose Set Access Permissions
Delete the Enable anonymous access ACI (click on the ACI, then click
Remove).
Since we have removed anonymous access, we must grant users rights to
see themselves in a different ACI. Thus, edit the "Allow self entry
modification except for nsroledn and aci attributes" ACI by adding
Search, Compare, and Read rights.
Add a new ACI to allow the global searcher (click on New, click on Edit
Manually and paste in the following:
(targetattr != "sambaLMPassword || sambaNTPassword || userPassword")
(version 3.0;
acl "Root Searcher";
allow (read,compare,search)
(userdn = "ldap:///uid=searcher,dc=mycompany, dc=com")
;)
Click Check Syntax to ensure there are no errors and then click on OK.
Create two more new ACIs to allow client browsing of their portion of
the Internal and External branches of the tree with the following two
stanzas - one for each ACI. Remember to click Check Syntax to ensure
there are no errors and then click on OK.:
(target = "ldap:///($dn),o=external,dc=mycompany,dc=com")(targetattr !=
"sambaLMPassword || sambaNTPassword || userPassword") (version 3.0;acl
"Client External Directory Searcher";allow (read,compare,search)(userdn
= "ldap:///uid=*searcher, [$dn],o=sysaccounts,dc=mycompany,dc=com");)
(target = "ldap:///($dn),o=internal,dc=mycompany,dc=com")(targetattr !=
"sambaLMPassword || sambaNTPassword || userPassword") (version 3.0;acl
"Client Internal Directory Searcher";allow (read,compare,search)(userdn
= "ldap:///uid=*searcher, [$dn],o=sysaccounts,dc=mycompany,dc=com");)
Create two more ACIs in the same way to allow client administrative
access to their portions of the tree with the following two ACIs:
(targetattr = "*") (target = "ldap:///($dn),o=external,dc=mycompany,
dc=com") (version 3.0;acl "Client Administrators External";allow
(all)(groupdn =
"ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");)
(targetattr = "*") (target = "ldap:///($dn),o=internal,dc=mycompany,
dc=com") (version 3.0;acl "Client Administrators Internal";allow
(all)(groupdn =
"ldap:///cn=*ldapadmins,ou=groups,[$dn],o=internal,dc=mycompany,dc=com");)
Now we need an explicit deny ACI to prevent client administrators from
adding or deleting users (this is how we determine their billing so they
must not change it). Use this ACI:
(targetattr = "") (target =
"ldap:///ou=Desktops,($dn),o=internal,dc=mycompany,dc=com") (version
3.0;acl "Client Internal Deny";deny (delete,add)(groupdn =
"ldap:///cn=*ldapadmins,ou=Groups,[$dn],o=Internal,dc=mycompany,dc=com");)
We need an ACI to allow the user account used to enumerate uids for the
DSGW application for each client to browse the client's portion of the
Internal tree. Use this ACI:
(target =
"ldap:///ou=Desks,($dn),o=Internal,dc=mycompany,dc=com")(targetattr =
"uid || st || sn || ou || name || entrydn || dn || dc || objectClass ||
cn || o || l || c || givenName") (version 3.0;acl "Client DSGW
Lister";allow (search,read)(userdn =
"ldap:///uid=*gwlister,[$dn],o=sysaccounts,dc=mycompany,dc=com");)
We need the following ACIs to allow users to see selected attributes of
all normally viewable entries in their own tree:
(target = "ldap:///($dn),o=external,dc=mycompany,dc=com")(targetattr =
"documentPublisher || documentTitle || physicalDeliveryOfficeName ||
preferredDeliveryMethod || documentVersion || subject || postalAddress
|| documentStore || roomNumber || drink || givenName || vacationenddate
|| documentAuthor || searchGuide || teletexTerminalIdentifier || mobile
|| manager || entrydn || objectClass || displayName || telexNumber ||
secretary || uid || certificateRevocationList || st || sn || description
|| mail || labeledUri || documentIdentifier || uidNumber ||
postOfficeBox || ou || seeAlso || registeredAddress || postalCode ||
photo || gidNumber || preferredTimeZone || title || uniqueMember ||
street || preferredLocale || presentationAddress || documentLocation ||
pager || dn || dc || o || cn || l || c || cACertificate ||
telephoneNumber || preferredLanguage || facsimileTelephoneNumber ||
memberOf || vacationstartdate") (version 3.0;acl "Client User Rights
External";allow (read,compare,search)(userdn =
"ldap:///uid=*,ou=Desks,[$dn],o=Internal,dc=mycompany,dc=com");)
(target = "ldap:///($dn),o=internal,dc=mycompany,dc=com")(targetattr =
"documentPublisher || documentTitle || physicalDeliveryOfficeName ||
preferredDeliveryMethod || documentVersion || subject || postalAddress
|| documentStore || roomNumber || drink || givenName || vacationenddate
|| documentAuthor || searchGuide || teletexTerminalIdentifier || mobile
|| manager || entrydn || objectClass || displayName || telexNumber ||
secretary || uid || certificateRevocationList || st || sn || description
|| mail || labeledUri || documentIdentifier || uidNumber ||
postOfficeBox || ou || seeAlso || registeredAddress || postalCode ||
photo || gidNumber || preferredTimeZone || title || uniqueMember ||
street || preferredLocale || presentationAddress || documentLocation ||
pager || dn || dc || o || cn || l || c || cACertificate ||
telephoneNumber || preferredLanguage || facsimileTelephoneNumber ||
memberOf || vacationstartdate") (version 3.0;acl "Client User Rights
Internal";allow (read,compare,search)(userdn =
"ldap:///uid=*,ou=Desks,[$dn],o=Internal,dc=mycompany,dc=com");)
Click OK to save the new ACIs.
Create three Organizations directly under dc=mycompany,dc=com, viz.,
Internal, External, and SysAccounts. Left/right click on mycompany,
choose New and then Other. Select organization from the ensuing dialog
and click OK. Replace "New" with the proper name in the name field and
click OK. Do this for each of the three new organizations.
Set a custom password policy for SysAccounts that users do not need to
change passwords after reset and passwords never expire. Left/right
click on SysAccounts in the right pane (<CTL> R if the window needs to
be refreshed) and choose Manage Password Policy, then For Subtree.
Enable Create subtree level password policy. Set the password syntax as
above (9 characters, 1 character category, 7 tokens). Click on Save and
then Close.
The admin server complains about not being able to determine the server
name on startup. To fix this problem,
edit /etc/dirsrv/admin-serv/httpd.conf and set ServerName
ldap1.mycompany.com:9830
Set the services to automatically start on boot:
chkconfig dirsrv-admin on
chkconfig dirsrv on
Configure SSL communication
Copy the ldap1admin PKCS#12 package generated as part of the PKI project
to /etc/dirsrv/admin-serv/.
Copy the CA cert (CA.pem) to /etc/dirsrv/admin-serv/ .
Change ownership and permissions, import the PKCS#12 package and CA cert
into Directory Admin Server with the following commands executed on
ldap1:
cd /etc/dirsrv/admin-serv
chown ldap:ldap CA.pem
chown ldap:ldap ldap1admin.p12
chmod 600 ldap1admin.p12
pk12util -i ldap1admin.p12 -d . (N.B. The terminal "." standing for the
current directory) Use the medium security SSI password to secure the
certificate store (the first password prompt)
certutil -A -d . -n "CA certificate" -t "CT,," -a -i CA.pem
Create a file in the /etc/dirsrv/admin-serv directory named
password.conf with the following contents:
internal:<the password>
Set permissions and ownership on it as follows:
chown ldap:ldap /etc/dirsrv/admin-serv/password.conf
chmod 0400 /etc/dirsrv/admin-serv/password.conf
Edit /etc/dirsrv/admin-serv/nss.conf to point the NSSPassPhraseDialog
parameter to file://etc/dirsrv/admin-serv/password.conf
At this point, we could delete ldap1admin.p12 but we will keep it just
in case we need it in the future.
Restart dirsrv-admin from the command line (NOT from the console)
(service dirsrv-admin restart)
Copy the ldap1 PKCS#12 package generated as part of the PKI project
to /etc/dirsrv/slapd-ldap1/.
Change ownership and permissions, import the PKCS#12 package and CA cert
into Directory Server with the following commands executed on ldap1:
cd /etc/dirsrv/slapd-ldap1
chown ldap:ldap ldap1.p12
chmod 600 ldap1.p12
pk12util -i ldap1.p12 -d . (N.B. The terminal "." standing for the
current directory) Use the medium security SSI password to secure the
certificate store (the first password prompt)
certutil -A -d . -n "CA certificate" -t "CT,," -a
-i /etc/dirsrv/admin-serv/CA.pem
Create a file in the /etc/dirsrv/slapd-ldap1 directory named pin.txt
with the following contents:
Internal (Software) Token:<the password>
Set permissions and ownership on it as follows:
chown ldap:ldap /etc/dirsrv/slapd-ldap1/pin.txt
chmod 0400 /etc/dirsrv/slapd-ldap1/pin.txt
Restart dirsrv (service dirsrv restart)
Open centos-idm-console (we want the full console this time and not just
the directory server (-s slapd-ldap1). Expand ldap1.mycompany.com,
expand Server Group, open the Directory Server (double click in left
panel or click Open on right panel).
Go to the Configuration tab of the Directory Server, click on the top
level item in the left panel (ldap1.mycompany.com:389), click on the
Encryption tab in the right panel.
Enable SSL
Check the Enable this cipher family:RSA check box
Click on the Settings button and uncheck any "none" or "RC2" ciphers.
Click OK
Enable Use SSL in Console
Click Save
Click OK on the warnings about setting taking effect only after restart
and having to start as root to use a port below 1024.
Return to the main console, open the Administration Server and go to the
Configuration tab, click on the top level item in the left panel
(Administration Server), click on the Encryption tab in the right panel.
Enable SSL
Check the Enable this cipher family:RSA check box
Click on the Settings button and uncheck any "none" or "RC2" ciphers.
Click OK
Go to the Configuration DS tab (authentication for the Directory
Services config directory)
Enable Secure Connection and make sure the port changes to 636.
Go to the User DS tab (configuration for the DIT (Directory Information
Tree))
Click Set User Directory
LDAP host and port: ldap1.mycompany.com:636
Click on Secure Connection
User Directory Subtree: dc=mycompany,dc=com (we need access to both
Internal and SysAccounts)
Click Save
Go to the Main Console
Click on mycompany.com in the left pane
Click on Edit at the bottom of the right pane
Click on Secure Connection and set the port to 636
Click on OK
Close all console windows
Stop the directory server (service dirsrv stop)
Restart the admin server (service dirsrv-admin restart)
If the restart fails with a error about NSSNickname only takes a single
argument, it is most likely because pk12util gave a nickname to the cert
with spaces in it. Edit the /etc/dirsrv/admin-serv/console.conf file at
the line indicated by the error and enclose the nickname in quotation
marks.
We may also want to edit /etc/dirsrv/admin-serv/httpd.conf by setting:
ServerName ldap1.mycompany.com:9830
in order to eliminate the cosmetic error about not determining the
server name.
Start the directory server (service dirsrv start)
We need to import the CA cert into the database of the
centos-idm-console user, i.e., the user running the GUI. In their home
directory is a .centos-idm-console. Enter that directory and issue the
following command (assuming it is running on the same computer as the
admin-server - otherwise change the CA cert source appropriately):
certutil -A -d . -n "CA certificate" -t "CT,," -a
-i /etc/dirsrv/admin-serv/CA.pem
Close the centos-idm-console if it is still running. Reopen it but be
sure to change the login Administration url to
https://ldap1.mycompany.com:9830 rather than http.
Click on the top level item in the left pane (mycompany.com), click edit
in the right pane, enable Secure connection and change the port on the
User directory host and port setting from 389 to 636.
Stop the directory server (service dirsrv stop)
Restart the administration server (service dirsrv-admin restart)
Start the directory server (service dirsrv start)
Set the services to automatically start on boot:
chkconfig dirsrv-admin on
chkconfig dirsrv on
Create read-only replica
The rest of these instructions assume one is on the ldap2 console unless
specified otherwise.
Create the ldap group and user
groupadd -g 6xx ldap
useradd -s /sbin/nologin -d /var/lib/dirsrv -g ldap -u 6xx ldap
Edit /etc/yum.repos.d/CentOS-Base.repo by enabling the centosplus
repository and adding the test repository with the following stanza:
[c5-testing]
name=CentOS-5 Testing
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=0
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
exclude=java-1.7.0-icedtea
Install the directory server:
yum --enablerepo=c5-testing install centos-ds
After centos-ds and its many dependencies have installed, install these
additional packages:
yum install xorg-x11-xauth bitstream-vera-fonts dejavu-lgc-fonts
urw-fonts firefox
We will need to trust the CA in order to connect to the existing
directory server via ldaps. Create the /etc/dirsrv/admin-serv
directory, copy the CA cert (CA.pem) into it, and set ownership and
permissions:
mkdir /etc/dirsrv/admin-serv
cd /etc/dirsrv/admin-serv
scp as appropriate
chown ldap:ldap CA.pem
chmod 660 CA.pem
We need to increase the number of allowable file handles.
Edit /etc/sysctl.conf by adding the following line:
fs.file-max = 64000
Run sysctl -p to effect the new settings
Add the following line to /etc/security/limits.conf
* - nofile 8192
Reboot ldap2 from the KVM console
Run setup-ds-admin.pl
Enter yes to continue and to accept the license terms
The setup routine will run dsktune and may issue a warning about file
handles. Enter yes to continue unless there is a more serious error.
Choose a custom installation (because we must specify the KVM guest
address)
The default Computer name should be fine (ldap2.mycompany.com)
System user is ldap
System group is ldap
We do to register with an existing directory server. The configuration
directory server is ldaps://ldap1.mycompany.com:636/o=NetscapeRoot
Administrator ID is someone
Password is <the password>
Administration domain is mycompany.com
The CA cert is in /etc/dirsrv/admin-serv/CA.pem
Take the default 389 port for now. We will implement LDAPS later
Directory server identifier is ldap2
Suffix is dc=mycompany,dc=com
Directory Manager DN is cn=Directory Manager
Use a different password
Do not install sample entries
We do not want any suggested entries so type none
Take the default administration port
IP address is 172.x.x.49
Run Administration Server as ldap
Enter yes to set up the servers
Start the console GUI with (the viewing computer must be running X and
using ssh X forwarding - configured in /etc/ssh/ssh_config - may need to
enable X11Trusted). Beware the idm-console windows open minimized:
centos-idm-console -a http://ldap2.mycompany.com:9830 -s slapd-ldap2
Login using cn=DirMan and the associated password
Click on the Configuration tab
Select the top level item in the tree on the left side
(ldap2.mycompany.com:389) and click on the SNMP tab. Fill in the
following details:
Name: ldap2-ds
Description: Directory Server on ldap2
Organization: My Company
Location: Data Center 1
Contact: Operators
Go to the SASL Mapping tab and add a new item with the following
details:
Name: kerberos uid mapping clients
Regular Expression: \(.*\)@\(.*\)\.\(.*\)
Search Base DN: dc=mycompany,dc=com
Search Filter: (uid=\1)
Click on Save
We will need to install the SAMBA schema. Copy the schema from the
SAMBA server (/usr/share/doc/samba-*/LDAP/samba.schema) and download the
schema importer
(http://directory.fedoraproject.org/download/ol-schema-migrate.pl)
Run the importer:
perl ol-schema-migrate.pl -b samba.schema
> /etc/dirsrv/slapd-ldap1/schema/61samba.ldif
Even easier, copy the already created 61samba.ldif file from the test
lab into /etc/dirsrv/slapd-ldap2/schema/
Change ownership and permissions on 61samba.ldif:
chown ldap:ldap 61samba.ldif
chmod 440 61samba.ldif
Restart the directory server (service dirsrv restart)
Return to the idm-console window, the Configuration tab, and click on
the Data object in the left panel
Click on the Passwords tab.
Enable fine grained password policy
User must change after reset
Keep six passwords
Password expires in 31 days
Warned four days before (to account for long weekends)
Allow 4 login attempts after expiration
Check password syntax to enforce minimum length of 9 characters with 3
character category and a token length of 2
Click the Account Lockout tab
Enable account lockout after 4 failures with a 10 minute reset. Lock
out for 10 minutes.
Click on Save
Expand Data, expand dc=mycompany,dc=com, go to the UserRoot database for
dc=mycompany,dc=com. Add the nsroledn attribute. Enable the presence
index for member, nsroledn, owner, seeAlso, and uniquemember. Click
Save.
Expand the Logs item in the left panel. Enable Audit logging allowing 5
logs rotating each week or 100 MB with total storage of 500 MB held for
40 months or delete when space is below 50MB. Click Save. Disable
Access logging. Click Save.
The admin server complains about not being able to determine the server
name on startup. To fix this problem,
edit /etc/dirsrv/admin-serv/httpd.conf and set ServerName
ldap2.mycompany.com:9830
Set the services to automatically start on boot:
chkconfig dirsrv-admin on
chkconfig dirsrv on
Configure SSL communication
Copy the ldap2admin PKCS#12 package generated as part of the PKI project
to /etc/dirsrv/admin-serv/.
Copy the CA cert (CA.pem) to /etc/dirsrv/admin-serv/ .
Change ownership and permissions, import the PKCS#12 package and CA cert
into Directory Admin Server with the following commands executed on
ldap2:
cd /etc/dirsrv/admin-serv
chown ldap:ldap CA.pem
chown ldap:ldap ldap2admin.p12
chmod 600 ldap2admin.p12
pk12util -i ldap2admin.p12 -d . (N.B. The terminal "." standing for the
current directory) Use the medium security SSI password to secure the
certificate store (the first password prompt)
certutil -A -d . -n "CA certificate" -t "CT,," -a -i CA.pem
Create a file in the /etc/dirsrv/admin-serv directory named
password.conf with the following contents:
internal:medium security SSI password
Set permissions and ownership on it as follows:
chown ldap:ldap /etc/dirsrv/admin-serv/password.conf
chmod 0400 /etc/dirsrv/admin-serv/password.conf
Edit /etc/admin-serv/nss.conf to point the NSSPassPhraseDialog parameter
to file://etc/dirsrv/admin-serv/password.conf
At this point, we could delete ldap2admin.p12 but we will keep it just
in case we need it in the future.
Restart dirsrv-admin from the command line (NOT from the console)
(service dirsrv-admin restart)
Copy the ldap2 PKCS#12 package generated as part of the PKI project
to /etc/dirsrv/slapd-ldap2.
Change ownership and permissions, import the PKCS#12 package and CA cert
into Directory Server with the following commands executed on ldap2:
cd /etc/dirsrv/slapd-ldap2
chown ldap:ldap ldap2.p12
chmod 600 ldap2.p12
pk12util -i ldap2.p12 -d . (N.B. The terminal "." standing for the
current directory) Use the medium security SSI password to secure the
certificate store (the first password prompt)
certutil -A -d . -n "CA certificate" -t "CT,," -a
-i /etc/dirsrv/admin-serv/CA.pem
Create a file in the /etc/dirsrv/slapd-ldap2 directory named pin.txt
with the following contents:
Internal (Software) Token:medium security SSI password
Set permissions and ownership on it as follows:
chown ldap:ldap /etc/dirsrv/slapd-ldap2/pin.txt
chmod 0400 /etc/dirsrv/slapd-ldap2/pin.txt
Restart the directory server (service dirsrv restart)
We need to import the CA cert into the database of the
centos-idm-console user, i.e., the user running the GUI. In their home
directory is a .centos-idm-console. Enter that directory and issue the
following command (assuming it is running on the same computer as the
admin-server - otherwise change the CA cert source appropriately):
certutil -A -d . -n "CA certificate" -t "CT,," -a
-i /etc/dirsrv/admin-serv/CA.pem
Open centos-idm-console (we want the full console this time and not just
the directory server (-s slapd-ldap2), open the Directory Server for
ldap2.
Go to the Configuration tab of the Directory Server, click on the top
level item in the left panel (ldap2.mycompany.com:389), click on the
Encryption tab in the right panel.
Enable SSL
Check the Enable this cipher family:RSA check box
Click on the Settings button and uncheck any "none" or "RC2" ciphers.
Click OK
Enable Use SSL in Console
Click Save
Click OK on the warnings about setting taking effect only after restart
and having to start as root to use a port below 1024.
Open the Administration Server for ldap2 and go to the Configuration
tab, click on the top level item in the left panel (Administration
Server), click on the Encryption tab in the right panel.
Enable SSL
Check the Enable this cipher family:RSA check box
Click on the Settings button and uncheck any "none" or "RC2" ciphers.
Click OK
Go to the Configuration DS tab
Enable Secure Connection and make sure the port changes to 636 and it
points to ldap1.mycompany.com and not ldap2 since ldap1 houses the DS
configuration.
Go to the User DS tab
Click on the Set User Directory radio button
Set LDAP host and port to ldap2.mycompany.com:636
ldap1.mycompany.com:636
Enable Secure Connection
Set User Directory Subtree to dc=mycompany,dc=com
Click Save
Open the ldap1 Administration Server and go to the Configuration tab,
click on the top level item in the left panel (Administration Server),
click on the Encryption tab in the right panel.
Go to the User DS tab
Click on the Set User Directory radio button
Set LDAP host and port to ldap1.mycompany.com:636
ldap2.mycompany.com:636
Enable Secure Connection
Set User Directory Subtree to dc=mycompany,dc=com
Click Save
Close all consoles.
Stop the directory server (service dirsrv stop)
Restart the admin server (service dirsrv-admin restart)
If the restart fails with a error about NSSNickname only takes a single
argument, it is most likely because pk12util gave a nickname to the cert
with spaces in it. Edit the /etc/dirsrv/admin-serv/console.conf file at
the line indicated by the error and enclose the nickname in quotation
marks.
Start the directory server (service dirsrv start)
Restart the admin server on ldap1.
Close the centos-idm-console if it is still running. Reopen it but be
sure to change the login Administration url to
https://ldap2/mycompany.com:9830 rather than http.
Setup replication
Create the Replication Manager entry on ldap2. Stop the directory
server on ldap2 (service dirsrv stop). Edit
the /etc/dirsrv/slapd-ldap2/dse.ldif file by adding the following
stanza:
dn: cn=repuser,cn=config
uid: repuser
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: repuser
givenname: Replication
sn: Manager
userPassword: <password>
passwordExpirationTime: 20380119031407Z
Start the directory server (service dirsrv start)
Argh! This always complains about trailing spaces. If it does, start
the Directory Server and use the GUI to delete the repuser user and then
create them with the above data. Be sure to change both the uid and cn
to repuser and the name attribute to cn. One must save the new user and
then edit the advanced properties after the first save in order to set
the passwordExpirationTime as above. Argh! Apparently we cannot change
the name attribute so, if we use this method, we must remember to use
uid=repuser instead of cn=repuser in the Replication Agreement created
below.
The repuser user must have a separate password policy so the password is
not required to be changed on login and does not expire. This is
normally done as done previously, i.e., left/right click on the repuser
user object in the ldap2 directory under cn=config. However, there is a
bug in the UI which frequently makes the password manager UI unusable.
If this is the case, we can create the password policy using the
following process on the ldap2 directory:
Left/right click on config in the left directory panel
Add new other and choose nscontainer object
Name the container "nsPwPolicyContainer"
Left/right click nsPwPolicyContainer and add new other and choose
passwordpolicy
Add a new object class of ldapsubentry
Add a cn attribute with value "cn=nsPwPolicyEntry,uid=repuser,cn=config"
Change the naming attribute to cn (button toward bottom right of dialog)
Hmm . . very strange, I was not looking forward to entering all the
different password policy attributes manually when I realized I had
mistyped the name of the nsPwPolicyEntry. I deleted the password policy
entity so the nsPwPolicyContainer was empty. Somehow, this enabled the
custom password policy to appear properly when right clicking the
repuser entity!
Hmm . . . it appears that, once we create the nsPwPolicyEntry, the menu
appears and can then be used to add all the other attributes.
THIS IS ALL FIXED IN 8.1
Go to the Directory Server GUI for ldap1 (this can now be done from
centos-idm-console on ldap1 or ldap2), choose the Configuration tab,
select Replication in the left panel and then the Supplier Settings in
the right panel.
Enable the Change Log
Click the Use default button
Click Save
Expand the Replication object and choose the userRoot database
Enable the replica
Set to single master
Give it a replica ID of 1
Click Save
Go to the Directory Server GUI for ldap2, choose the Configuration tab.
Expand the Replication object and choose the userRoot database
Enable the replica
Set to dedicated consumer
Enter cn=repuser,cn=config in the Enter a new Supplier DN field and
click Add. Click on Save.
Go to the Directory tab
Left/right click on config in the left panel and choose properties. Set
the passwordisglobalpolicy to on. Click OK.
Go back to the centos-idm-console on ldap1
Go to the Configuration tab, select the userRoot under the Replication
object in the left panel. Left/right client and choose New Replication
Agreement
The name is "mycompany.com ldap1->ldap2" and the Description is
"Replicates mycompany.com from ldap1 to ldap2". Click Next.
Set the Consumer to ldap2.mycompany.com:389 from the drop down box (389
is correct even though we are really using 636) - Oops! That is not true
despite what the documentation says. Click other and create a new entry
for ldap2.mycompany.com on port 636.
Enable the SSL connection.
Enter cn=repuser,cn=config for the Bind As and enter the password.
Click Next and then Next again.
We will always keep directories in sync so click Next again.
Choose Initialize Consumer Now and click Next
Click Done
Setup DSGW for client user administration
We will install DSGW on ldap1 so clients can administer their own users.
Thus, we will significantly restrict what DSGW can do.
The Centos RPMs for the web based user interface have not yet been
released. In the meantime, we can download the DSGW source from
http://directory.fedoraproject.org/sources/fedora-ds-dsgw-1.1.1.tar.bz2
(1.1.2 is available but fails to compile for an unmet dependency)
yum install wget tar gzip bzip2
mkdir /download
cd /download
wget
http://directory.fedoraproject.org/sources/fedora-ds-dsgw-1.1.1.tar.bz2
These have some dependencies so we must do - oops!
For some reason, there is a broken dependency setting for httpd-devel so
we will need to download it manually after installing its dependencies:
yum install apr-devel apr-util-devel pkgconfig
cd /download
wget
http://dev.centos.org/centos/5/testing/x86_64/httpd-devel-2.2.8-1.el5s2.centos.x86_64.rpm
rpm -Uvh httpd-devel*.rpm
Now we can do:
yum --enablerepo=c5-testing install icu libicu-devel mozldap-devel
apr-devel pam-devel openssl-devel lm_sensors-devel net-snmp-devel
cyrus-sasl gcc-c++ bzip2 make nspr-devel nss-devel adminutil-devel file
svrcore-devel
As a non-root user, untar the dsgw tarball and make dsgw:
useradd -m someuser
chown -R someuser /download
su someuser
cd /download
tar jxfv fedora-ds-dsgw-1.1.1.tar.bz2
cd fed*
./configure --prefix=/usr --libdir=/usr/lib64 --sysconfdir=/etc
--localstatedir=/var && make && su -c "make install"
exit (to root)
Copy the CA cert into /etc/dirsrv/dsgw so we can use LDAPS.
cp /etc/dirsrv/admin-serv/CA.pem /etc/dirsrv/dsgw/
Now we configure DSGW by running setup-ds-dsgw
We want to prevent any access to the Directory Manager account so we
edit /etc/dirsrv/dsgw/dsgw.conf by commenting out the current dirmgr
directory and creating a new one for the non-existent user
"Intentionally Broken"
dirmgr "cn=Intentionally Broken"
Change the baseurl parameter in dsgw.conf to use port 636 (LDAPS). It
may have detected ldaps during installation and already be set properly.
We want to remove the hyperlinks to local server administration. To do
this, edit /usr/share/dirsrv/html/admserv.html by commenting out the two
table rows (<tr></tr>) containing the "CentOS Home Page" and the CentOS
Administration Express". While we are editing, change the
<title></title> to SSI Directory Management Console and CentOS Server
Products (note the breaks in between) to SSI Directory Management. In
fact, we may want to comment out the user services altogether. We may
also wish to rename the files to which the links point so they cannot be
found explicitly by someone who has researched DSGW.
mv /usr/share/dirsrv/html/htmladmin.html{,x}
Because we do not allow anonymous access, we need a binddn and bindpw to
access the tree. Since this is a client application, that will be
different for each client. We will store the various bind information
files in /etc/dirsrv/bindings so we need to make that directory:
mkdir /etc/dirsrv/bindings
dsgw.conf needs a binddnfile directive but we will add this on a per
client basis. Thus we will construct customized files combining the
binddnfile and a template which is simply the dsgw.conf file without the
binddnfile directive. Thus do:
cd /etc/dirsrv/dsgw
cp dsgw.conf dsgw.template
chown ldap:ldap /etc/dirsrv/dsgw/dsgw.template
Restart dirsrv-admin
The service is now available from https://ldap1.mycompany.com:9830
BECAUSE WE STARTED WITH 8.0, WE HAD TO UPGRADE TO 8.1 WITH SOMETHING
SIMILAR TO THIS PROCEDURE. IT MAY CONTAIN IMPORTANT INFORMATION FOR YOU
ldap2
SSH to ldap2 as root
Backup the current database as follows:
cd /usr/lib64/dirsrv/slap*
./db2ldif -n userRoot -a /tmp/ssi.<datestamp>.ldif
mv /tmp/ssi*.ldif ~/ (it seems we cannot save it here directly - I
assume the backup process does not run as root but rather as ldap)
Update centos ds as follows:
yum --exclude=kernel --enablerepo=c5-testing upgrade
Argh!! silly bug - because we are using ldaps, it asks for the CA cert
but then complains that the CA cert is already installed. To work
around the bug we need to uninstall the CA cert first with:
certutil -D -d /etc/dirsrv/admin-serv -n "CA certficate"
setup-ds-admin.pl -u
Add the new plugins as follows:
service dirsrv stop
service dirsrv-admin stop
Copy the contents of /usr/share/dirsrv/data/template-dse.ldif
and /usr/share/dirsrv/data/template-dnaplugin.ldif
into /etc/dirsrv/slapd-ldap2/dse.ldif
Argh!! The MemberOf definition has an error in it. Change
memberOfGroupAttr from member to uniqueMember and change
nsslapd-pluginenabled from off to on.
service dirsrv start
service dirsrv-admin start
ldap1
SSH to ldap1 as root
Backup the current database as follows:
cd /usr/lib64/dirsrv/slap*
./db2ldif -n userRoot -a /tmp/ssi.<datestamp>.ldif
./db2ldif -n NetscapeRoot -a /tmp/ssi-config.<datestamp>.ldif
mv /tmp/ssi*.ldif ~/
Update centos ds as follows:
yum --exclude=kernel --exclude=postgresql-libs --enablerepo=c5-testing
upgrade
setup-ds-admin.pl -u
Add the new plugins as follows:
service dirsrv stop
service dirsrv-admin stop
Copy the MemberOf definition
from /usr/share/dirsrv/data/template-dse.ldif and the contents
of /usr/share/dirsrv/data/template-dnaplugin.ldif
into /etc/dirsrv/slapd-ldap1/dse.ldif
Argh!! The MemberOf definition has an error in it. Change
memberOfGroupAttr from member to uniqueMember and change
nsslapd-pluginenabled from off to on.
service dirsrv start
service dirsrv-admin start
Another Argh!! The memberOf plugin requires each user on whom it should
operate to have the inetuser object class which is not created by
default. We need to add it to each user.
Add group membership to existing users as follows:
fixup-memberof.pl
Hmm . . . it cannot find fixup-memberof.pl so we try to do this with
ldapmodify as follows:
/usr/lib64/mozldap/ldapmodify -h ldap01 -D "cn=Directory Manager" -w -
-ZZZ -P /etc/dirsrv/admin-serv
Enter bind password:
dn: cn=fixMemberOf,cn=memberof task,cn=tasks,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: fixMemberOf
basedn: o=Internal,dc=mycompany,dc=com
filter: (objectClass=inetOrgPerson)
<enter twice then CTL D>
LDAP Active Directory Integration
This procedure outlines setting up clients with Windows users by
integrating their Active Directory with the main LDAP directory.
Unlike non-Windows client setups, we need to create the client Internal
organization ( e.g., o=abcdefgh,o=Internal,dc=mycompany,dc=com) before
the main user creation routine. This is because the synchronization
agreement between LDAP and AD must be in place before the users are
created lest the users be created disabled with passwords which must be
changed at the first login. We will thus alter the clientsetup script
to not fail automatically if it finds the Internal client organization
already exists but will give the administrator a choice to continue.
We will use a flag named ADINT to keep track of what to do with AD
integration. It may have one of three values:
1.0 = The Internal client organization does not exist which implies no
AD integration
2.1 = The Internal client organization does exist but the WTSUser group
has not yet been created
3.2 = The Internal client organization does exist as does the WTSUser
group so we simply add the Windows enabled user to that group.
We begin by creating the client Internal organization in LDAP. Right
click o=Internal and choose new other and then choose organization.
We next go to the Windows domain controller and create organizational
units named Desktops and Groups underneath the top level of AD, e.g., at
dc=mycompany,dc=com. Right click on the top level of the domain and
choose New / Organizational Unit.
We create a user in the main cn=Users context of Active Directory to
function as the binddn for LDAP. The user must be a member of the
domain admins group.
We go to centos-idm-console -s slapd-ldap1 on ldap1 to administer LDAP.
Go to the configuration tab. Expand Replication and right click on
UserRoot. Choose New Windows Sync Agreement.
Give it an appropriate and unique name and a description. Enter the
Windows domain name as appropriate; it should be the FQDN of the top
level of AD, e.g., mycompany.com. Do NOT check Sync New Windows Users
or Sync New Windows Groups as we do not want this information pushed
from Windows to LDAP. We only want to go from LDAP to Windows.
Synchronize with the top level of AD so we can access both users and
groups in separate OUs, e..g, dc=mycompany,dc=com. The top level
should synchronize with the client's Internal organization in LDAP,
e.g., o=abcdefgh,o=Internal,dc=ssiservices,dc=biz. Enter the hostname
for the domain controller and port 636. Check "Using encrypted SSL
connection" and enter the credentials for the AD synchronization user
created earlier. Click next and done. If there is a problem connecting
to the LDAP server, it may be a bad password, bad binddn, or bad
hostname.
Left/right click on the new windows synchronization agreement under
Replication / UserRoot in the left panel and choose Initiate Full
Synchronization. Check the Replication status on the Status tab to
ensure it was successful.
Next, create the new users using the clientsetup script as normal.
Answer "Y" to the question if it is OK that the client ID already
exists.
Once the objects have been created in LDAP, go to the configuration tab,
left/right click on the Windows synchronization agreement and Send and
Receive Updates Now. Go to the Windows Terminal Server console and open
the Terminal Services Configuration utility. Double click the RDP-tcp
connection. Go to the permissions tab and add the WTSUsers group (it
will be named WTSUsers-<a unique client identifier>). Set the
permissions to User Allow for the WTSUsers group.
LDAP configurations
Now that we have defined the SSI users, we need to install and configure
the LDAP client and related modules for all installed servers. We will
start with host01. First copy the CA cert (CA.pem)
into /etc/pki/tls/certs/ and ensure it is world readable. Then:
yum install nscd nss_ldap authconfig
authconfig --update --enableldap --enableldapauth --disablenis
--enablecache --ldapserver=ldapxx.mycompany.com
--ldapbasedn=dc=mycompany,dc=com --enableldaptls
We must edit the resultant /etc/ldap.conf file as follows:
binddn uid=searcher,o=abcdefg,o=SysAccounts,dc=mycompany,dc=com
Oops! This is the case on all servers except this one as this one needs
to see all the client data thus:
binddn uid=searcher,dc=ssiservices,dc=biz
bindpw <searcher password>
rootbinddn <the ldap administrator DN> (we will not set this for the
guests systems on this vserver host)
tls_cacertfile /etc/pki/tls/certs/CA.pem (toward the bottom)
uri ldap://ldapxx.mycompany.com/
ssl start_tls
pam_password md5
tls_checkpeer yes
comment out tls_certdir
Create the /etc/ldap.secret file containing the passphrase and set it rw
for root only (chmod 600 /etc/ldap.secret).
Edit /etc/nscd.conf to change the group positive cache limit
(positive-time-to-live) to 600 seconds from the default 3600.
Otherwise, group changes may take up to an hour to propagate.
Edit /etc/pam.d/system-auth by changing:
password sufficient pam_unix.so shadow nullok try_first_pass
use_authtok
to
password sufficient pam_unix.so md5 shadow nullok try_first_pass
use_authtok
(addition of md5) lest we only use the first eight characters of any
password. It looks like this is the new default setting so no need to
change it.
Setup SAMBA
In order for Windows Terminal Server users to see their data from their
TS sessions, TS needs to map a drive to their data stored on host01.
Thus, we need to install SAMBA and integrate it with LDAP. First, we
install the needed packages:
yum install samba samba-client samba-common
Then edit /etc/samba/smb.conf from the default values as follows:
[global]
workgroup = WORKGROUP
server string = HOST01 Version %v
interfaces = lo bond0 172.x.x.8/16
disable netbios = yes
large readwrite = yes
Standalone Server Options
security = user
passdb backend = ldapsam:ldap://ldapxx.mycompany.com
ldap ssl = start_tls
ldap admin dn =
uid=admin,ou=administrators,ou=topologymanagement,o=netscaperoot
ldap suffix = dc=mycompany,dc=com
ldap delete dn = no
Browser Control Options
local master = no
Printing Options
; load printers = yes (i.e., comment it out)
[homes]
Comment out everything including the heading - we not want to map home
drive access by default
[printers]
Comment out everything including the heading - we do not want to expose
all printers
[data-template]
writable = yes
create mask = 0770
directory mask = 0770
browseable = no
case sensitive = yes
block size = 4096
follow symlinks = no
# ====== abcdefgh Shares ============
[data-abcdefgh]
copy = data-template
path = /data/clients/abcdefgh
valid users = user1 user2
hosts allow = windows1.mycompany.com
Create the secrets.tdb file to store the searcher password:
smbpasswd -w <password>
history -c
Add password to PasswordLocations file
Edit /etc/openldap/ldap.conf (NOT /etc/ldap.conf) by setting
TLS_CACERT /etc/pki/tls/certs/CA.pem
Start the SAMBA service and set it to start on boot:
service smb start
chkconfig smb on
Modifying SAMBA LDAP users
Add needed object classes to the user by doing the following from
host01:
smbpasswd -a <userID> (enter current password - we have a problem in
that there is currently no way to change the smbpasswd from LDAP - just
the other way around)
Although we are still not sure this is doing anything as all sources
seem to say we cannot sync passwords from LDAP to SAMBA, just the other
way around, without implementing FreeIPA, edit /etc/pam.d/system-auth-ac
so the password section reads as follows:
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password sufficient pam_smbpass.so use_authtok
password sufficient pam_ldap.so use_authtok
password required pam_deny.so
END
I think that is just about everything we did. Perhaps it is more
confusing than helpful and it certainly needs to be adapted. Wish I had
more time to do that for you but it's time to shackle up my chains, head
back to the pile and break more IT rocks. Good luck - John
--
John A. Sullivan III
Open Source Development Corporation
Street Preacher: Are you SAVED?????!!!!!!
Educated Skeptic: Saved from WHAT?????!!!!!!
Educated Believer: From our selfishness that hurts the ones we love
and condemns us to an eternity of hurting each other.
http://www.spiritualoutreach.com
Christianity that makes sense
More information about the Fedora-directory-users
mailing list