> Has anyone successfully deployed OpenLDAP for central auth in a very mixed unix environment? With Host
> based access control? Plus any documentation would be really great.
> My needs;
> - Central Auth
> - Host based access control (e.g. user "John" from group "accounts" can't log into "development servers".
> - Caching for Client logins on laptops. I figure SSSD will be useful here?
> - Encryption (This looks pretty straight forward in the OpenLDAP 2.4 doco)
> Client OS's involved;
> - Solaris 9/10
> - Fedora 15/16
> - Centos 5/6
A solution which will cover most of Your needs is in production here:
- Solaris 9/10 (working on 11)
- HPUX 11.x
- AIX 5/6
Host based access control:
- nis-netgroups for hosts
- nis-netgroups for users
- members of user-netgroup 'oracle_dba' can log into machines from host-netgroup 'oracle_db_server'
Role based access control:
- sudo profiles for each role
- sudoUser by user-netgroups (example: 'oracle_dba')
- sudoHost by host-netgroups (example: oracle_db_server')
Pretty much straight forward from standard docs.
I need some urgent advices on the openldap-scheme extension.
My openldap version is slapd 2.4.23 on a debian squezze machine.
When I try to activate vacation on the webmail-system roundcube (the
webmailer and the plugins are working fine) it says the the activation is
stored, but when I have a look into the logs of round cube, they say:
[16-Dec-2011 11:20:29] Could not add new values to attribute vacationActive:
Object class violation: LDAP_OBJECT_CLASS_VIOLATION (65):
[16-Dec-2011 11:20:29] Could not modify entry: Could not add new values to
attribute vacationActive: Object class violation:
The slapd-logs shows the following when I try to activate vacation:
conn=1221 op=4 MOD dn="cn=admin,dc=domain,dc=de"
slapd: conn=1221 op=4 MOD attr=vacationActive
serv slapd: slap_queue_csn: queing 0xb58969b6
serv slapd: Entry (cn=ldapadmin,dc=folkwang-hochschule,dc=de),
attribute 'vacationActive' not allowed
serv slapd: entry failed schema check: attribute 'vacationActive' not
serv slapd: conn=1221 op=4 RESULT tag=103 err=65 text=attribute
'vacationActive' not allowed
The following is my vacation.schema which I add to /etc/ldap/slapd.conf:
attributetype ( 184.108.40.206.4.1.39220.127.116.11
DESC 'A flag, for marking the user as being away'
SYNTAX 18.104.22.168.4.1.1422.214.171.124.7 )
attributetype ( 126.96.36.199.4.1.39188.8.131.52
DESC 'Absentee note to leave behind, while on vacation'
EQUALITY octetStringMatch )
attributetype ( 184.108.40.206.4.1.39220.127.116.11
DESC 'Beginning of vacation'
EQUALITY octetStringMatch )
attributetype ( 18.104.22.168.4.1.3922.214.171.124
DESC 'End of vacation'
EQUALITY octetStringMatch )
DESC 'Where to forward mails to, while on vacation' )
# Objects start here
objectclass ( 126.96.36.199.4.1.39188.8.131.52 NAME 'vacation'
SUP top AUXILIARY
DESC 'Users vacation status information'
MAY ( vacationInfo $ vacationStart $ vacationEnd $ vacationForward )
I imported a user with the object class vacation and the attributes
vacationActive, vacationInfo . into my ldap database.
There the import looks fine.
The user has got the privileges to modify the vacation attributes.
But when I try to modify the entries via vacation-plugin on roundcube, the
above errors occur.
Can anybody give me some advices, please?
Has anyone successfully deployed OpenLDAP for central auth in a very mixed unix environment? With Host based access control? Plus any documentation would be really great.
- Central Auth
- Host based access control (e.g. user "John" from group "accounts" can't log into "development servers".
- Caching for Client logins on laptops. I figure SSSD will be useful here?
- Encryption (This looks pretty straight forward in the OpenLDAP 2.4 doco)
Client OS's involved;
- Solaris 9/10
- Fedora 15/16
- Centos 5/6
i've installed succefully, ppolicy overlay and ldap password policy
objects my directroy.
So what do i expected for now ?
because nothing happened. we are using jamm mail account schemas and sample
accounts very old, and i expected expire all of them but nothing happened.
what is the correct settigns of ppolicy_default_dn ?
we are using openldap on redhat EL6 with postfix and JAMM schema. I wantto
activate password policy for ldap but
i cannot add default password schema ,
i try to apply step that tells on
but i cannot add dn: cn=default,ou=policies,dc=myhosting,dc=example class,
ldap_bind: Invalid DN syntax (34)
additional info: invalid DN
what is the problem ?
thanks in advance
I want to add a new objectclass using an ldif; this objectclass requires
some attributes (according to schema). I can't make it work.
For posixAccount class, required attributes are:
I already have cn and uid.
I am trying:
and it fails.
I've tried other ways too, like including existing objectclasses in the
LDIF (I've read about that in a blog), using a separate add statement
for optional attribute loginShell, etc. but nothing worked.
If the ObjectClass to add does not specify REQUIRED attributes in the
schema, there is no problem in adding it.
How should I formulate the LDIF?
I'm trying to grok Mozilla NSS prior to deploying Openldap 2.4.23 on RHEL 6.2. I've been working through creating a self-signed cert and I think I have one that works. At least, if I do:
[root@animal ~]# certutil -d /etc/pki/nssdb/ -L
Certificate Nickname Trust Attributes
the its cert is the one I used to sign.
If I do:
[root@animal ~]# certutil -d /etc/pki/nssdb/ -L -n animal.clarku.edu
Then I see a normal looking cert:
Version: 3 (0x2)
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=ITS Self Signed"
Not Before: Mon Dec 12 16:01:27 2011
Not After : Mon Mar 12 16:01:27 2012
Subject: "CN=animal.clarku.edu,O=Clark University ITS,L=Worcester,ST=
Here's what I've got in cn=config:
If do those commands as the ldap user with sudo -u ldap, I get the same output. I can even run "certutil -V -n animal.clarku.edu -u SR -d /etc/pki/nssdb/" and I get "certificate is valid".
However when I start slapd, I get:
[root@animal slapd.d]# service slapd start
animal.clarku.edu is not readable by "ldap" [WARNING]
Starting slapd: [ OK ]
What am I missing?
Manager of Systems Administration
Clark University ITS
Looking for guidance on an ldap+NFS4+Kerberos puzzle in a mixed OS local
Simple demo case, four computers on a little net.
box 1: Running openlap server, kerberos KDC, kadmin, lets say it's
running freebsd, doesn't matter. nfs server & client.
box 2: Linux box. nfs server & client.
box 3: *bsd/Solaris box. nfs server & client.
box 4: misc user box, could be *bsd or *nix.
Networking: Nfs4 secured with kerberos. That means No uid/gid numbers
on the wire, only user@box. NSS is active on all boxes, reaching out
to the ldap server on box 1 for info for what is not in the local passwd
file searched first.
Popular package X gets installed on box 2 and box 3. Package X is a
drop-root privilege package, has its own uid/gid!=0. It is active on
the net, might write log files or get data files via nfs on either of
the other two computers in the setup. The maintainers for package X in
the *bsd world have chosen a different number for the uid / gid for the
package X daemon than the maintainers for package X have chosen in the
*nix world. Those get written in the local passwd file on each system
at package X install / download time.
Note: Package X does _not_ get installed on the ldap server box #1, or
box #4. There is no entry in the #1 or #4 system's passwd file for nss
to find for the daemon associated with package X. nfsuserd via nss must
find the package X user in ldap or the files will be unreadable or seem
'owned' by nobody:nogroup on 1 or 4 if say config or log files
edited/accessed from there.
Puzzle: What should the posixAccount uidNumber and gidNumber value be
in ldap for uid=packageXdaemon?
1: Choose no entry, leave it out of the ldap db: PackageXDaemon's files
will be owned by nobody:nogroup on box 1. Security Fail.
2: Choose *nix for the uid/gid in the ldap database on box 1. Fail:
The files will be stored with a uid/gid that might collide with another
account in the passwd database on the *bsd server.
3: Choose *bsd for the uid/gid in the ldap database on box 1: Fail:
The *nix user on box 4's nfsuserid will get the bsd uid/gid from ldap
which could create files not actually owned by something colliding in
the *nix passwd database on box 4.
4: Instead storing all the users once under an ou=Account... create
ou=AccountBSD and ou=AccountNix, duplicate the whole account tree but
vary the apropos uid/gid pair under each tree with all the other
remaining equal, manage collisions when amending the database. Not so
5: Edit the schema to replace uidNumber and gidNumber with uidNixNumber
/ uidBsdNumber & etc. for gid. Breaks code expecting standard uidNumber
gidNumber in the default ldap schemas.
There are so many packages that could be X, you can imagine not wanting
to have to qualify and patch all of them to use a common uid/gid
number. (And it gets even worse in a mixed nfs3 / nfs4 environment
where uid/gid numbers actually go over the wire in some cases, and
user@box in others, let's leave that to the side for now).
I'm leaning toward #5 to avoid storing all the other account information
under two different trees. But I'd prefer a scheme were there is a
not-edited standard schema tree stored once under 'ou=Account' but with
a different overlay for the uid/gid elements if looked up as AccountNix
I'm sure someone has done battle with this already, what's the right
First, I'm running 2.4.27
A year and a half ago, running 2.4.something-less-than-27, we installed a
device which queried LDAP and was causing a load on the ldap servers. I found
it was looking for an attribute we didn't have.
I indexed the attribute and I believed that the load was reduced.
I did not add the objectclass which offered the attribute to our objectclasses.
Was I imagining things?
Recently, we have another black box that queries ldap. I can't control the
attributes which it requests.
I added the attributes to the index and ran the slapindex and no new .bdb files
were generated, even using the -q -t flags, which claims to truncate a database
before scanning for the attribute. That sounded like a way to maybe trick it
into making an empty database, but no dice.
As an experiment, I ran slapadd to create a new database, with those attributes
in the index list. It didn't add any of them, nor did it create that single
attribute which I believed I had "fixed" last year. I'm reasonably sure that
prior openldap versions of both slapindex and slapadd would create the index
for an attribute listed as indexed without it appearing in the data.
I'm curious to know if I was wrong that indexing an attribute would speed the
search even if the attribute did not appear in the schemas used.
Also, does this mean that I have to add whatever schema that new ldap-client
black-box wants to search in order to make the index in order to reduce that
client's ldap server load?
Thanks for any insights.