synapse unsync

First some background stuff - this work was all done on Centos 5.3 i386 using openldap 2.3. You need a basic working OpenLDAP configuration such as in my notes Configuring OpenLDAP. The other thing you need to be aware of when setting up LDAP sync with the Centos 5.x distro is that, like RedHat, the syncprov module is statically linked with slapd which means that the notes that refer to using the moduleload functionality with syncprov.la do not apply to Centos. LDAP sync replication is essentially a “pull” replication model which is different from the deprecated slurpd’s “push” replication.

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.

No comments »

These notes refer to building rssh on Centos 5.3. I do not cover chrooting the user within their restricted shell because I could not get it working satisfactorily. Nor do I cover the reasons why you might want to use a restricted shell.

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.

No comments »

How to make freeradius use openldap as an authentication source.
This was tested on Centos 5.3. Freeradius and OpenLDAP were installed using the “Add/Remove Software” item on the Applications menu - no rocket science here! The article assumes that you already have a working ldap server (or see my article on Configuring OpenLDAP).

(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

No comments »

This was used to configure OpenLDAP on Centos 5.3

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.

No comments »