Ver2.4.23 - Delta syncrepl stops responding
by david m
I have a problem that has just started happening in the last few
weeks. Replication of modifications and/or adds from one LDAP node to
the other will work fine ( repl time <1s) for a while, then suddenly
stop working all together. The only way to get replication working
again is to restart each node 2 or 3 times (sometimes it comes back
after 2 restarts, sometimes it takes 3). On the last restart, I
usually find that one node is stuck in an infinite loop trying to
process a transaction from the other node's accesslog - the only way
to get around this is to delete the the accesslog entry (see below for
accesslog entry and slapd output). Any ideas?
OS: OpenSuse 11.1 64-bit w/ 2GB RAM
Version: OpenLDAP 2.4.23
Network Setup: 2 read/write nodes, with delta syncrepl between the nodes
SERVER 1 Configs:
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAuthzRegexp:
{0}gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth
dn:cn=config
olcLogLevel: stats sync
olcPidFile: /var/run/slapd/slapd.pid
olcServerID: 1 ldap://LDAP1:389
olcServerID: 2 ldap://LDAP2:389
olcSizeLimit: 10000
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by dn.base="cn=admin,o=o" manage
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.base="cn=admin,o=o" manage
olcAccess: {1}to * by * read
olcRootDN: cn=config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcAccess: {0}to
attrs=pwdChangedTime,pwdAccountLockedTime,pwdFailureTime,pwdHistory,pwdGraceUseTime,pwdReset
by * none
olcAccess: {1}to attrs=userPassword by self write by * auth by
dn.base="cn=admin,o=o" manage
olcAccess: {2}to attrs=shadowLastChange by self write by * read
olcAccess: {3}to attrs=userPKCS12 by self read by * none
olcAccess: {4}to * by * read by dn.base="cn=admin,o=o" manage
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 151200000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 151200000
olcDbIndex: objectclass eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: member eq
olcDbIndex: memberUid eq
olcDbIndex: mail eq
olcDbIndex: cn eq,sub
olcDbIndex: displayName eq,sub
olcDbIndex: uid eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: givenName eq,sub
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcLimits: {0}dn.exact="cn=admin,o=o" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcMirrorMode: TRUE
olcRootDN: cn=admin,o=o
olcRootPW: {SSHA}PWD
olcSuffix: o=o
olcSyncrepl: {0}rid=2
provider=ldap://LDAP2:389
binddn="cn=admin,o=o"
bindmethod=simple
credentials=PWD
searchbase="ou=USERS,o=o"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=off
type=refreshAndPersist
retry="60 +"
syncdata=accesslog
dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=Default Policy,o=o
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE
dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 100 1
olcSpSessionlog: 100
dn: olcOverlay={2}accesslog,olcDatabase={1}hdb,cn=config
objectClass: olcAccessLogConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcAccessLogDB: cn=accesslog
olcOverlay: {2}accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 03+00:00 01+00:00
olcAccessLogSuccess: TRUE
dn: olcDatabase={2}accesslog,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap_accesslog
olcAccess:: ezB9dG8gKiBieSBkbi5iYXNlPSJjbj1hZG1pbixvPWNvIiBtYW5hZ2Ug
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 9948000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 9948000
olcDbIndex: entryCSN eq
olcDbIndex: objectClass eq
olcDbIndex: reqEnd eq
olcDbIndex: reqResult eq
olcDbIndex: reqStart eq
olcDbIndex: default eq
olcLimits: {0}dn.exact="cn=admin,o=o" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcSuffix: cn=accesslog
dn: olcOverlay={0}syncprov,olcDatabase={2}accesslog,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 1
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
olcSpSessionlog: 100
dn: olcDatabase={3}monitor,cn=config
objectClass: olcMonitorConfig
olcDatabase: {3}monitor
olcAccess: {0}to * by dn.base="cn=admin,o=o" manage
olcAccess: {1}to * by * none
olcMonitoring: true
--------------------------
SERVER 2 Configs:
version: 1
dn: cn=config
objectClass: olcGlobal
cn: config
olcArgsFile: /var/run/slapd/slapd.args
olcAuthzRegexp:
{0}gidNumber=0\+uidNumber=0,cn=peercred,cn=external,cn=auth
dn:cn=config
olcLogLevel: stats sync
olcPidFile: /var/run/slapd/slapd.pid
olcServerID: 1 ldap://LDAP1:389
olcServerID: 2 ldap://LDAP2:389
olcSizeLimit: 10000
dn: olcDatabase={-1}frontend,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {-1}frontend
olcAccess: {0}to dn.base="" by * read
olcAccess: {1}to dn.base="cn=Subschema" by * read
olcAccess: {2}to * by dn.base="cn=admin,o=o" manage
dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to * by dn.base="cn=admin,o=o" manage
olcAccess: {1}to * by * read
olcRootDN: cn=config
dn: olcDatabase={1}hdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {1}hdb
olcDbDirectory: /var/lib/ldap
olcAccess: {0}to
attrs=pwdChangedTime,pwdAccountLockedTime,pwdFailureTime,pwdHistory,pwdGraceUseTime,pwdReset
by * none
olcAccess: {1}to attrs=userPassword by self write by * auth by
dn.base="cn=admin,o=o" manage
olcAccess: {2}to attrs=shadowLastChange by self write by * read
olcAccess: {3}to attrs=userPKCS12 by self read by * none
olcAccess: {4}to * by * read by dn.base="cn=admin,o=o" manage
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 151200000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 151200000
olcDbIndex: objectclass eq
olcDbIndex: uidNumber eq
olcDbIndex: gidNumber eq
olcDbIndex: member eq
olcDbIndex: memberUid eq
olcDbIndex: mail eq
olcDbIndex: cn eq,sub
olcDbIndex: displayName eq,sub
olcDbIndex: uid eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: givenName eq,sub
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
olcLimits: {0}dn.exact="cn=admin,o=o" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcMirrorMode: TRUE
olcRootDN: cn=admin,o=o
olcRootPW: {SSHA}PWD
olcSuffix: o=o
olcSyncrepl: {0}rid=1
provider=ldap://LDAP1:389
binddn="cn=admin,o=o"
bindmethod=simple
credentials=PWD
searchbase="ou=USERS,o=o"
logbase="cn=accesslog"
logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
schemachecking=off
type=refreshAndPersist
retry="60 +"
syncdata=accesslog
dn: olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcPPolicyConfig
olcOverlay: {0}ppolicy
olcPPolicyDefault: cn=Default Policy,o=o
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE
dn: olcOverlay={1}syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {1}syncprov
olcSpCheckpoint: 100 1
olcSpSessionlog: 100
dn: olcOverlay={2}accesslog,olcDatabase={1}hdb,cn=config
objectClass: olcAccessLogConfig
objectClass: olcOverlayConfig
objectClass: olcConfig
objectClass: top
olcAccessLogDB: cn=accesslog
olcOverlay: {2}accesslog
olcAccessLogOps: writes
olcAccessLogPurge: 03+00:00 01+00:00
olcAccessLogSuccess: TRUE
dn: olcDatabase={2}accesslog,cn=config
objectClass: olcDatabaseConfig
objectClass: olcHdbConfig
olcDatabase: {2}hdb
olcDbDirectory: /var/lib/ldap_accesslog
olcAccess:: ezB9dG8gKiBieSBkbi5iYXNlPSJjbj1hZG1pbixvPWNvIiBtYW5hZ2Ug
olcDbCheckpoint: 1024 5
olcDbConfig: {0}set_cachesize 0 9948000 1
olcDbConfig: {1}set_lg_regionmax 262144
olcDbConfig: {2}set_lg_bsize 2097152
olcDbConfig: {3}set_flags DB_LOG_AUTOREMOVE
olcDbIDLcacheSize: 9948000
olcDbIndex: entryCSN eq
olcDbIndex: objectClass eq
olcDbIndex: reqEnd eq
olcDbIndex: reqResult eq
olcDbIndex: reqStart eq
olcDbIndex: default eq
olcLimits: {0}dn.exact="cn=admin,o=o" time.soft=unlimited
time.hard=unlimited size.soft=unlimited size.hard=unlimited
olcSuffix: cn=accesslog
dn: olcOverlay={0}syncprov,olcDatabase={2}accesslog,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: {0}syncprov
olcSpCheckpoint: 100 1
olcSpNoPresent: TRUE
olcSpReloadHint: TRUE
olcSpSessionlog: 100
dn: olcDatabase={3}monitor,cn=config
objectClass: olcMonitorConfig
olcDatabase: {3}monitor
olcAccess: {0}to * by dn.base="cn=admin,o=o" manage
olcAccess: {1}to * by * none
olcMonitoring: true
--------------------------
Bad accesslog entry & slapd output
version: 1
####From Transaction recorded in accesslog on LDAP1
dn: reqStart=20111212033402.000002Z,cn=accesslog
objectClass: auditModify
reqAuthzID: cn=admin,o=co
reqDN: cn=bob,ou=users,o=co
reqEnd: 20111212033402.000003Z
reqMod: userPassword:= {SSHA}PWD
reqMod: pwdChangedTime:= 20111212033402Z
reqMod: entryCSN:= 2011 12 12 03 34 02.374746Z#000000#001#000000
reqMod: modifiersName:= cn=admin,o=o
reqMod: modifyTimestamp:= 20111212033402Z
reqResult: 0
reqSession: 3296
reqStart: 20111212033402.000002Z
reqType: modify
#####Log Of LDAP2 after 2nd restart (No Related Log info on LDAP1
during that timeframe)
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b639100 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b568240 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b639100 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b568240 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b639100 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b568240 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b639100 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b568240 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b639100 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b568240 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b639100 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b568240 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b639100 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_queue_csn: queing
0x7f093b746ea5 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: slap_graduate_commit_csn: removing
0x7f093b568240 20111212033402.374746Z#000000#001#000000
Dec 12 07:54:43 LDAP2 slapd[2732]: do_syncrep2: rid=001
cookie=rid=001,sid=001,csn=20111212033402.374746Z#000000#001#000000
9 years, 3 months
re: OpenLDAP for Central Auth?
by Juergen.Sprenger@swisscom.com
Hi Craig,
> Hi,
>
> 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
>
>
> cya
>
> Craig
A solution which will cover most of Your needs is in production here:
Central Auth
Client OS's:
- Solaris 9/10 (working on 11)
- HPUX 11.x
- AIX 5/6
- Fedora/Redhat
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')
Encryption: tls/ssl
Pretty much straight forward from standard docs.
Juergen Sprenger
9 years, 3 months
Trying to add vacation.schema - object class violation error
by Andreas Cieslak
Hi list,
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:
LDAP_OBJECT_CLASS_VIOLATION: (1000):
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[14608]: conn=1221 op=4 MOD attr=vacationActive
serv slapd[14608]: slap_queue_csn: queing 0xb58969b6
20111216110200.012914Z#000000#000#000000
serv slapd[14608]: Entry (cn=ldapadmin,dc=folkwang-hochschule,dc=de),
attribute 'vacationActive' not allowed
serv slapd[14608]: entry failed schema check: attribute 'vacationActive' not
allowed
serv slapd[14608]: 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 ( 1.3.6.1.4.1.39116.1.1.11
NAME 'vacationActive'
SINGLE-VALUE
EQUALITY booleanMatch
DESC 'A flag, for marking the user as being away'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 )
attributetype ( 1.3.6.1.4.1.39116.1.1.12
NAME 'vacationInfo'
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
DESC 'Absentee note to leave behind, while on vacation'
EQUALITY octetStringMatch )
attributetype ( 1.3.6.1.4.1.39116.1.1.13
NAME 'vacationStart'
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
DESC 'Beginning of vacation'
EQUALITY octetStringMatch )
attributetype ( 1.3.6.1.4.1.39116.1.1.14
NAME 'vacationEnd'
SINGLE-VALUE
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
DESC 'End of vacation'
EQUALITY octetStringMatch )
attributetype (1.3.6.1.4.1.39116.1.1.15
NAME 'vacationForward'
EQUALITY caseIgnoreIA5Match
SUBSTR caseIgnoreIA5SubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{256}
DESC 'Where to forward mails to, while on vacation' )
#
# Objects start here
#
objectclass ( 1.3.6.1.4.1.39116.1.2.10 NAME 'vacation'
SUP top AUXILIARY
DESC 'Users vacation status information'
MUST vacationActive
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?
Thanks
Andreas
9 years, 3 months
OpenLDAP for Central Auth?
by Craig T
Hi,
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
cya
Craig
9 years, 3 months
Password Policy Effects
by Selcuk Yazar
Hi
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 ?
thanks inadvance.
--
Selçuk YAZAR
http://www.selcukyazar.blogspot.com
9 years, 3 months
Password Policy
by Selcuk Yazar
Hi,
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
http://www.zytrax.com/books/ldap/ch6/ppolicy.html
but i cannot add dn: cn=default,ou=policies,dc=myhosting,dc=example class,
it gives
ldap_bind: Invalid DN syntax (34)
additional info: invalid DN
error.
what is the problem ?
thanks in advance
[image: image.png]
--
Selçuk YAZAR
http://www.selcukyazar.blogspot.com
9 years, 3 months
Adding an object class with required attributes to an existing entry
by Nick Milas
Hi,
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:
cn
gidNumber
homeDirectory
uid
uidNumber
I already have cn and uid.
I am trying:
dn: uid=userx,ou=people,dc=example,dc=com
changetype: modify
add: ObjectClass
objectClass: posixAccount
uidNumber: 1700
homeDirectory: /var/members/userx
gidNumber: 48
loginShell: /bin/false
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?
Please advise.
Thanks,
Nick
9 years, 3 months
Mozilla NSS / OpenLdap 2.4.23 cert not readable?
by Aaron Bennett
Hello,
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
SSL,S/MIME,JAR/XPI
its Cu,Cu,Cu
animal.clarku.edu p,p,p
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:
Certificate:
Data:
Version: 3 (0x2)
Serial Number:
00:96:7c:e7:ea
Signature Algorithm: PKCS #1 SHA-1 With RSA Encryption
Issuer: "CN=ITS Self Signed"
Validity:
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=
Massachusetts,C=US"
Here's what I've got in cn=config:
olcTLSCACertificatePath: /etc/pki/nssdb/
olcTLSCertificateFile: animal.clarku.edu
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?
Thanks,
Aaron
---
Aaron Bennett
Manager of Systems Administration
Clark University ITS
9 years, 3 months
Ldap+Nfsv4+kerberos *nix / *bsd puzzle.
by Harry Coin
Hello group!
Looking for guidance on an ldap+NFS4+Kerberos puzzle in a mixed OS local
environment.
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?
Alternatives:
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
pretty.
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
or AccountBsd.
I'm sure someone has done battle with this already, what's the right
answer?
Thanks
Harry Coin
9 years, 3 months
slapdindex
by Allan E. Johannesen
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.
9 years, 3 months