These notes relate to a simple ldap sync setup with 1 provider and 1 consumer. In LDAP sync jargon a “provider” is the source of updates and a “consumer” is the openldap which is to be updated. There are various models for ldap sync, in this version which is the simplest all the data for all records are copied when there is a change but there are more sophisticated models which only copy the changes. This can be useful if you have a large directory.

The provider has only 2 configuration directives for setting checkpoints on the contextCSN and configuring the session log. Because ldap sync search is subject to access control you must ensure proper acl privileges are set for the replicated content.

In the provider’s slapd.conf add:

index entryCSN,entryUUID    eq,pres

then add:

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

limits dn.exact="cn=syncuser,dc=mydomain,dc=com" size=unlimited time=unlimited

The limits entry is a good idea to help keep the consumer in sync during a large modification.

I also added a syncuser to my directory with an ldif like:

dn: cn=syncuser,dc=mydomain,dc=com
uid: syncuser
cn: syncuser
sn: syncuser
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: e1NTSEF9NERla1JTSWwxa0tDU0FHRU5SUVZudVh4L1VyamJ1dFQ=
shadowLastChange: 14387
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 501
gidNumber: 501
homeDirectory: /home/syncuser
gecos: syncuser

On the consumer add in slapd.conf:

index entryCSN,entryUUID    eq,pres

and then:

syncrepl rid=101
    provider=ldap://ldap.mydomain.com:389
    type=refreshOnly
    interval=00:01:00:00
    searchbase="dc=mydomain,dc=com"
    filter="(objectclass=*)"
    attrs="*,+"
    scope=sub
    schemachecking=off
    bindmethod=simple
    binddn="cn=syncuser,dc=mydomain,dc=com"
    credentials=secret

where:
rid=101 is the id for this query; it must be unique across all consumers
provider=xx is the server this consumer will query
type=refreshOnly means that after the initial sync the sync query will rerun at the time specified by interval
interval=00:01:00:00 means the sync query will reschedule after 1 hour
searchbase=xx the start at the root of the tree
filter="(objectclass=*)" look for everything
scope=sub search recursively
attrs="*,+" copy all attributes which is the default setting so there is no need to specify this
schemachecking=off the provider should already be doing this
binddn=xx is the user on the provider who the consumer will use for its queries
bindmethod=simple use plaintext passwords
credentials=secret the syncuser password

There are other options, instead of type=refreshOnly you could have type=refreshAndPersist which means that after the initial query the sync will stay open and any other changes will be transferred immediately. If you change your type setting you may want to remove the interval setting and add retry="60 +" which means that if network connectivity is lost between the consumer and the provider, the consumer will try every 60 seconds indefinitely to re-establish a network connection with the provider.

Now restart slapd on the provider and then on the consumer.

Main site is a VMWare ESX 3.5 HA cluster (Intel CPUs) and SAN with multiple VMFS filesystems. Remote site (300K from main office) is a single VMWare server (AMD CPUs) with 2 VMFS filesystems on RAIDed internal storage. The 2 sites are connected by 10Mbps optical fibre. Both sites are managed through Virtual Center which is installed into a VM in our main site. To backup our main site VMs (including Virtual Center) we decided to use vReplicator from Vizioncore.

Installation was very easy, just run the installer and follow the prompts to set it up - we installed vReplicator into the same VM as our Virtual Center installation. vReplicator logged in to our VC and discovered our HA cluster, the VMs it contained and also our remote server and its VMs.

Using it was just as easy, you select the VM you want to replicate, click the “Create Job” link and complete the details. There are dropdowns for resources like VMFS filesystems on the target and you can select which of the VM’s disks replicate to which remote VMFS filesystem.

Which type of replication? We used what vReplicator refers to as “Differential” replication which is essentially a point-in-time comparison of original and replicated VMs and uses a VM snapshot to capture changed data. The other type of replication supported by vReplicator is called “Hybrid”. Hybrid replication uses a “change over time” model to identify what should be replicated. It is faster because there is no need to scan during the replication pass but uses more disk space for its (2) snapshots. It was largely because of constraints on the amount of disk space available for snapshots that we selected “Differential” replication.

Once you save a job you can leave it to autostart at the time/date you designated or you can run the job now by clicking the “Run” menu item for the job. The first replication takes quite some time as the entire VM has to be copied. Subsequent runs are much quicker. In our case a replicate job for a fairly static VM which took 3 hours for the first run takes around 30mins for 2nd and subsequent runs; another job for our main SQLServer2005 VM which took 11 hours for the first run takes about 2-3 hours for 2nd and subsequent runs.

At the moment we are replicating 4 VMs, all Windows 2003, including our Virtual Center VM and 2 SQLServer database installations (different vesions). Shortly we will be adding Centos 5.x Linux VMs with our mailserver and Samba installations.

So vReplicator in a nutshell, easy to install, easy to setup and configure and easy to run. Things to watch out for are that you have enough space for the snapshots that vReplicator uses and that you have enough bandwidth to move the amount of data you want to move in the time window you have available.

Separately to the VM replication outlined above we have an additional Linux VM in our remote site which has a redundant DNS server, a synchronised OpenLDAP replication configuration and a redundant RADIUS server. These servers provide secondary DNS, radius and authentication services for both our main site, our remote site and regional offices.

The steps I followed were:

Get the code
(1) download the source rpm (2.3.2 at time of writing)
(2) install the gpg key
  rpm --import http://www.pizzashack,org/ddmkey.txt
(3) build the source package
  rpmbuild -v --rebuild rssh-2.3.2-1.src.rpm
(4) install the newly built rpm
  rpm -ivh /usr/src/redhat/RPMS/i386/rssh-2.3.2-1.i386.rpm

Configuring rssh (no chroot)
(1) edit the /etc/rssh.conf file and uncomment the #allowsftp line (and/or #allowscp and/or #allowrsync etc) to allow sftp access (and/or scp and/or rsync etc)
(2) create your user (eg for a user John Citizen)
  useradd -m -d /home/jcitizen -s /usr/bin/rssh jcitizen
passwd jcitizen
(3) test the login for jcitizen from another machine
   (a) connect using ssh
   ssh jcitizen@rsshserver.mydomain.com

   you should see output something like:

Last login: Sat Apr 25 11:00:11 2009 from 192.168.0.10

This account is restricted by rssh.
Allowed commands: scp sftp rsync

If you believe this is in error, please contact your system administrator.

Connection to rsshserver.mydomain.com closed.

   (b) connect using sftp
   sftp jcitizen@rsshserver.mydomain.com

   You should now see some output something like:

Connecting to rsshserver.mydomain.com...
jcitizen@rsshserver.mydomain.com's password:
sftp>

(4) Important - note that this type of configuration will apply to all users with the rssh shell. It is also possible to configure rssh on a per user basis.

(1) In radiusd.conf edit the modules section for ldap so that it reads something like:

ldap {
server = "myhost.mydomain.com"
identity = "cn=manager,dc=mydomain,dc=com"
password = mysecret
basedn = "dc=mydomain,dc=com"
filter = "(uid=%u)"
start_tls = no
access_attr = uid
dictionary_mapping = $(raddbdir/ldap.attrmap
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
}

(2) Find the authorize section of radiusd.conf find the line which starts #ldap and remove the '#' so it reads just ldap

(3) Again in radiusd.conf, but in the authentication section, find the lines:

# Auth-Type LDAP {
#     ldap
#}

and remove the '#' so these lines read

Auth-Type LDAP {
     ldap
}

(4) In the /etc/raddb/users file find the section which reads

DEFAULT Auth-Type = System
     Fall-Through = 1

and replace it with

DEFAULT Auth-Type = LDAP
     Fall-Through = 1

(5) Restart the radiusd daemon /etc/init.d/radiusd restart
(6) Assuming that your /etc/raddb/clients.conf has a section that reads

clients 127.0.0.1 {
     secret = testing123
     shortname = localhost
     nastype = other
}

and also that you have an entry in your ldap directory like

dn: uid=john,ou=users,dc=mydomain,dc=com
uid: john
cn: john
givenName: john
sn: doe
mail: john@mydomain.com
mailRoutingAddress: john@mail.prod.mydomain.com
mailHost: mail.prod.mydomain.com
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$EwO.4wlT$n5KoIfFE8qcDcPAC12vxn2
shadowLastChange: 14360
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 503
gidNumber: 503
homeDirectory: /home/john
gecos: john doe

and that jdoe’s password is mysecret, you can test your radius configuration by executing

radtest john mysecret 127.0.0.1 10 testing123

You should see a reply like

Sending Access-Request of id 65 to 127.0.0.1 port 1812
    User-Name = "jdoe"
    User-Password = "secret"
    NAS-IP-Address = 255.255.255.255
    NAS-Port = 10
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=65, length=20

Initial Configuration of slapd.conf
(1) You need the following schemas included:

include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/inetorgperson.schema
include /etc/openldap/schema/nis.schema

(2) depending on what you might be planning for your ldap server you might also want to include:

include /etc/openldap/schema/misc.schema
include /etc/openldap/schema/RADIUS-LDAPv3.schema

(3) For these initial tests I am not going to configure TLS but for a production system you should be using TLS

(4) enable an acl that will allow users to modify their own information
access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
by self write
by users read
by anonymous auth

(5) configure your suffix and rootdn
suffix "dc=mydomain,dc=com"
rootdn "cn=manager,dc=mydomain,dc=com"

(6) generate your management password with the command

slappasswd -s secret -h {SSHA}

where -s specifies the password to encrypt and -h the encryption scheme. Use man slappasswd for more information. Paste the output into your slapd.conf file as:

rootpw {SSHA}D74b0UDGxQ43biWJXCNLTw1Q+MsAlvti

(7) Now save your slapd.conf file

(8) Start ldap with

/etc/init.d/ldap start

To make ldap start automatically whenever the system starts chkconfig ldap on

Create the Directory Contents
Creating the initial user and group ldif import files
(1) download the current version of the padl migration scripts from http://www.padl.com/OSS/MigrationTools.html

(2) unpack the tools (eg. use the command ‘tar zxvf MigrationTools.tgz’ which will create a subdirectory such as MigrationTools-47 with the padl migration scripts in the current directory)
(3) cd in to the newly created scripts directory
(4) edit the migrate_common.ph script (eg. vi migrate_common.ph) and set the following variables to appropriate values:
$DEFAULT_MAIL_DOMAIN = "mydomain.com";
$DEFAULT_BASE = "dc=mydomain,dc=com";
$DEFAULT_MAIL_HOST = "mail.prod.mydomain.com";
$EXTENDED_SCHEMA = 1;

I also updated all the cn=Xxx values to all lowercase but this is just my personal preference
(5) Unless you are using Kerberos and have the appropriate schema loaded into your slapd.conf you should also edit the migrate_common.ph script so that the lines

# Default Kerberos realm
if ($EXTENDED_SCHEMA) {
$DEFAULT_REALM = $DEFAULT_MAIL_DOMAIN;
$DEFAULT_REALM =~ tr/a-z/A-Z/;
}
are commented out thus
# Default Kerberos realm
#if ($EXTENDED_SCHEMA) {
# $DEFAULT_REALM = $DEFAULT_MAIL_DOMAIN;
# $DEFAULT_REALM =~ tr/a-z/A-Z/;
#}

(6) Assuming your initial passwd, shadow and group files are located in the directory above your current working directory you can now use the commands …

./migrate_passwd.pl ../passwd.in ../passwwd_out.ldif
./migrate_group.pl ../group.in ../group_out.ldif

… to generate your ldif import files

For a sample passwd, shadow and group file that only contains the 1 user with the following information

passwd: john:x:503:503:john doe:/home/john:/bin/bash
shadow: john:$1$EwO.4wlT$n5KoIfFE8qcDcPAC12vxn2:14360:0:99999:7:::
group: john:x:503:
users:x:100:john

you will get the following passwd_out.ldif information:

dn: uid=john,ou=users,dc=mydomain,dc=com
uid: john
cn: john
givenName: john
sn: doe
mail: john@mydomain.com
mailRoutingAddress: john@mail.prod.mydomain.com
mailHost: mail.prod.mydomain.com
objectClass: inetLocalMailRecipient
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$EwO.4wlT$n5KoIfFE8qcDcPAC12vxn2
shadowLastChange: 14360
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 503
gidNumber: 503
homeDirectory: /home/john
gecos: john doe

and group_out.ldif information

dn: cn=users,ou=groups,dc=mydomain,dc=com
objectClass: posixGroup
objectClass: top
cn: users
userPassword: {crypt}x
gidNumber: 100
memberUid: john

dn: cn=john,ou=groups,dc=mydomain,dc=com
objectClass: posixGroup
objectClass: top
cn: john
userPassword: {crypt}x
gidNumber: 503

Create Containers For Users And Groups

(1) the contents of the file mydomain.com_ldap_init.ldif:

# Set up the origanisation container
dn: dc=mydomain,dc=com
objectclass: dcObject
objectclass: organization
o: Neologix Pty Ltd
dc: neologix

# set up a users container
dn: ou=users,dc=mydomain,dc=com
objectclass: organizationalUnit
ou: users

# set up a groups container
dn: ou=group,dc=mydomain,dc=com
objectclass: organizationalUnit
ou: group

# set up a hosts container
dn: ou=hosts,dc=mydomain,dc=com
objectclass: organizationalUnit
ou: hosts

(2) Initialize the directory
ldapadd -x -D 'cn=manager,dc=mydomain,dc=com' -W -f ./mydomain.com_ldap_init.ldif

(3) Add the users and groups (files are ldap_passwd.ldif and ldap_group.ldif cwd) to the ldap directory using the files you created above

ldapadd -x -D 'cn=manager,dc=mydomain,dc=com' -W -f ./ldap_passwd.ldif
ldapadd -x -D 'cn=manager,dc=mydomain,dc=com' -W -f ./ldap_group.ldif

(4) Now test your directory
(a) searching for everything
ldapsearch -x -D'cn=manager,dc=mydomain,dc=com' -b'dc=mydomain,dc=com' -W '(objectclass=*)'

(b) reset a user password
ldappasswd -D"cn=manager,dc=mydomain,dc=com" -x -W -S "uid=john,ou=users,dc=mydomain,dc=com"

You should now have a basic, working ldap directory server.

(1) The freeradius configuraton files are usually in /etc/raddb; make a subdirectory /etc/raddb/etc
(2) copy your /etc/passwd and /etc/shadow  files to /etc/raddb/etc
(3) edit the /etc/raddb/etc/passwd and /etc/raddb/etc/shadow files to remove all entries except for those that you want to authenticate with radius
(4) edit the /etc/raddb/radiusd.conf file; find the section:


unix {
...

and set the values for the passwd and shadow files so they read:


passwd = /etc/raddb/etc/passwd
shadow = /etc/raddb/etc/shadow


(5) save radiusd.conf
(6) make sure the radiusd user can read  the files

chmod -R 644 /etc/raddb/etc

(7) check the /etc/raddb/users file to ensure that the following exists:

DEFAULT     Auth-Type = System
Fall-Through = 1

(8) Assuming you have entries in the /etc/raddb/etc/passwd and /etc/raddb/etc/shadow for a user ‘jdoe’ with password of ’secret’ you can test your radius configuration by:
(a) start the radius daemon with ‘/etc/init.d/radiusd start’; you should see some output something like:

[root@myserver raddb]# /etc/init.d/radiusd start
Starting RADIUS server: Sun May  3 13:26:37 2009 : Info: Starting - reading configuration files … [  OK  ]

(b) execute the command ‘radtest jdoe secret 127.0.0.1 10 testing123′. Assuming it all works you should see output something like:


[root@myserver raddb]# radtest jdoe secret 127.0.0.1 10 testing123
Sending Access-Request of id 65 to 127.0.0.1 port 1812
User-Name = “jdoe”
User-Password = “secret”
NAS-IP-Address = 255.255.255.255
NAS-Port = 10
rad_recv: Access-Accept packet from host 127.0.0.1:1812, id=65, length=20


Note that the radius client password is the cleartext password specified for the client in clients.conf and the nas-port-number parameter can be any value between 0 and 2^31 so 10 is fine.

If you received the Access-Accept message then congratulations, you have radius working, if not then go back and check your configuration and permissions.

(9) You can have the radius daemon start automatically by executing ‘chkconfig radiusd on’

Some Background
NTP runs on UDP port 123 so you should ensure that this port is unblocked on your server’s firewall. NTP servers advertise their presence every 64 seconds by means of a multicast address 224.0.1.1. An ntp client that is not configured with the unicast address of an NTP server multicasts when its xntpd (or ntpd) process starts and then sends request packets to the unicast address of all the ntp servers it can locate. The request packet contains the client’s UTC time; when the ntp server responds it places it’s utc time in the reply.

Which Stratum?
NTP servers are organised into a hierarchy of levels called stratum.

Stratum 1 is the highest level. Servers on this level are usually interfaced directly to highly accurate time sources such as atomic clocks. These servers are not usually used for direct time sync, instead lower level servers are used.

Stratum 2 servers usually belong to large institutions such as universities and large commercial organisations. Servers in this stratum can be used directly for time sync (check the servers usage policies or use one of the ntp pool time servers) but large organisations usually have their own in house ntp server which will sync off a stratum 2 server and then provide time information to all inhouse systems.

Below stratum 2, some organisations will have their own time sources such as specialist time servers that sync of the time signal used by GPS satellites.

Some Jargon

• Strata NTP servers are arranged in a hierarchy called strata. A stratum-1 server is more accurate than a stratum-2 server etc. Although there are 15 strata only the first 3 are normally used.
• Drift A drift file usually the frequency offset of the local system’s clock oscillator. Drift file contents can be used by protocols, like NTP, to cause a system’s clock to be more accurate.
• xntpd The SUN NTP daemon. Other OSes may use ntpd as their ntp daemon. Depending on which Linux you use you may have either xntpd or ntpd as your ntp daemon.
• ntp.conf The ntpd configuration file that controls the behaviour of the ntp daemon. For Solaris this is usually found in /etc/inet, for Linux this is usually found in /etc.
• fudge You can use the fudge utility in the ntp.conf file as a keyword to configure reference clocks in special ways. These notes do not delve into fudge to any extent.

Configuration
On Solaris Sun provide a template ntp configuration file, /etc/inet/ntp.server, that you should copy to /etc/inet/ntp.conf and then customize to obtain the configuration for your network.

Edit your new ntp.conf

# vi /etc/inet/ntp.conf

Ensure that the following line exists in your ntp.conf:
broadcast 224.0.1.1 ttl 4

Replace
server 127.127.XType.0
fudge 127.127.XType.0 stratum 0

with
server 0.pool.ntp.org
server 1.pool.ntp.org
server 2.pool.ntp.org
#fudge 127.127.XType.0 stratum 0

Make sure the drift file exists
# touch /var/ntp/ntp.drift

Make sure the stats file exists
# touch /var/ntp/ntpstats

Note, if you have different names/locations for your drift and stats files then use those instead of the examples above.

Make an initial sync of your server’s clock:
# ntpdate 0.pool.ntp.org

Start the ntp daemon:
# svcadm online ntp

Issuing the command
# svcs -a | grep ntp

should now show something like
# online 9:12:22 svc:/network/ntp:default

Your ntp daemon is now running. The ntpq command should show you the status of your ntp daemon’s synchronisation:


# ntpq -p
remote refid st t when poll reach delay offset disp
==============================================================================
NTP.MCAST.NET 0.0.0.0 16 u - 64 0 0.00 0.000 16000.0
-cachens2.onqnet clock.via.net 2 u 792 1024 377 39.15 4.198 0.92
+203-80-163-174- ntp1.tpgi.com.a 3 u 954 1024 377 26.14 -2.018 0.82
+ntp.tourism.wa. csiro-nml.physi 2 u 852 1024 377 106.00 -3.111 1.60
*ns.tti.net.au ntp.melbourne.n 2 u 805 1024 377 30.79 0.522 1.14


To set the timezone in /etc/default/init you edit the TZ variable so that, for example:

TZ="Australia/Canberra"

The full list of timezones is in /usr/share/lib/zoneinfo/

After changing the timezone you should restart the system.

What seems to happen is that the network does not startup before the Ctrl+Alt+Del and login dialog appears. If the workstation is left for about 5-10 minutes the problem usually goes away. Occasionally though the problem becomes so persistent that no matter how often you reboot and regardless of how long you wait the PDC remains uncontactable. The problem is intermittent and inconsistent, for some workstations it will always happen, for others it only appears sporadically.

How to get around it? I’ve found that forcing windows to start its networking synchronously during the initial workstation startup seems to fix the problem. Making this happen requires a change to registry settings so save the following with a filename of <somefile>.reg …

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\CurrentVersion\Winlogon]
“SyncForegroundPolicy”=dword:00000001

[HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Winlogon]
“SyncForegroundPolicy”=dword:00000001

According the docs at Microsoft’s Technet site setting this value to dword 1 causes the operating system to “Always wait for the network at computer startup and logon.” Why two different registry settings? Microsoft’s docs say that the first entry in the Policies section of the registry is all that is needed but when inspecting a workstation registry one day I found this actual attribute (with a setting of dword 0) in the second branch of the registry … “so to be sure, to be sure” I’ve added it in both locations.