openldap-technical December 2011

openldap-technical@openldap.org

88 participants
101 discussions

Ver2.4.23 - Delta syncrepl stops responding
by david m 19 Dec '11

19 Dec '11

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

2 1

re: OpenLDAP for Central Auth?
by Juergen.Sprenger＠swisscom.com 19 Dec '11

19 Dec '11

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

2 1

Trying to add vacation.schema - object class violation error
by Andreas Cieslak 19 Dec '11

19 Dec '11

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

3 4

OpenLDAP for Central Auth?
by Craig T 19 Dec '11

19 Dec '11

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

5 7

Password Policy Effects
by Selcuk Yazar 18 Dec '11

18 Dec '11

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

1 0

Password Policy
by Selcuk Yazar 17 Dec '11

17 Dec '11

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

2 2

Adding an object class with required attributes to an existing entry
by Nick Milas 16 Dec '11

16 Dec '11

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

3 6

Mozilla NSS / OpenLdap 2.4.23 cert not readable?
by Aaron Bennett 16 Dec '11

16 Dec '11

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

4 8

Ldap+Nfsv4+kerberos *nix / *bsd puzzle.
by Harry Coin 16 Dec '11

16 Dec '11

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

3 3

slapdindex
by Allan E. Johannesen 16 Dec '11

16 Dec '11

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.

1 0

← Newer
1
2
3
4
5
6
7
...
11
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2011