openldap-software

openldap-software@openldap.org

2719 discussions

[Fwd: Re: KDC {K5KEY} userPassword problem] Solved!!
by Kent Nasveschuk 05 Dec '07

05 Dec '07

Although I specified in slapd.conf on the slave servers: moduleload /opt/openldap-2.3.39/lib/smbk5pwd.la I omitted: overlay smbk5pwd I'm guessing slapd never passed credentials to KDC, hence the (49) error code. 1 more question, how does the smbk5pwd module handle a Kerberos password that is expired? Is there a specific error code? I suppose I could expire one then try it. 2 days of wrestling with this, finally got it to work. -- Kent L. Nasveschuk Systems Administrator Marine Biological Laboratory 7 MBL Street Woods Hole, MA 02543 Tel. (508) 289-7263

2 1

Problem with K5KEY implementation
by Kent Nasveschuk 05 Dec '07

05 Dec '07

Hello, I'm having a problem with OpenLDAP using Heimdal Kerberos via the {K5KEY} entry in userPassword. The problem is with the second KDC, works fine on the master LDAP/KDC just not the second one. Some info: This is an OpenLDAP server with Heimdal storing Kerberos stuff in LDAP. Master (mbauth01) Slave (mblauth02) OSs: CentOS5 OpenLDAP 2.3.39 Heimdal 1.0.1 On the second KDC I can use kadmin -l and do klist -l Princ and get results fine, so I know that the KDC can talk to the LDAP backend via ldapi. I don't think it is acls because I removed all and get the same result. >From a remote machine if I search the master: ldapsearch -Z -x -h mblauth01.mbl.edu -b ou=users,dc=mbl,dc=edu -D cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn I get results >From a remote machine if I search the slave: ldapsearch -Z -x -h mblauth02.mbl.edu -b ou=users,dc=mbl,dc=edu -D cn=<some user>,ou=users,dc=mbl,dc=edu -w <krb5 password> cn=<user> cn I get: ldap_bind: Invalid credentials (49) It doesn't look like the mechanism in LDAP that refers userPassword with {K5KEY} to KDC is working on the slave machine. A couple things might cause this to fail. The {K5KEY} entry never made it from the Master to the slave via syncrepl. I verified that the entries are there. I also changed a password using kadmin cpw and verified that the change was replicated to the slave and they were. Any suggestions on how to troubleshoot this or get it working. Couple things about slapd.conf. I added write access to ldapi which should be read on the slave. The password-hash directive not quite sure what that should be set at. On the master it works fine with this omitted. slapd.conf on slave: include /opt/openldap-2.3.39/etc/openldap/schema/core.schema include /opt/openldap-2.3.39/etc/openldap/schema/cosine.schema include /opt/openldap-2.3.39/etc/openldap/schema/inetorgperson.schema include /opt/openldap-2.3.39/etc/openldap/schema/nis.schema include /opt/openldap-2.3.39/etc/openldap/schema/autofs.schema include /opt/openldap-2.3.39/etc/openldap/schema/samba.schema include /opt/openldap-2.3.39/etc/openldap/schema/RADIUS-LDAPv3.schema include /opt/openldap-2.3.39/etc/openldap/schema/hdb.schema #include /opt/openldap-2.3.39/etc/openldap/schema/rfc822.schema include /opt/openldap-2.3.39/etc/openldap/schema/qmail.schema include /opt/openldap-2.3.39/etc/openldap/schema/mblPerson.schema schemacheck on sasl-realm MBL.EDU sasl-host mblauth02.mbl.edu sasl-authz-policy both sasl-regexp "uidNumber=0\\\ +gidNumber=.*,cn=peercred,cn=external,cn=auth" "cn=admin,ou=users,dc=mbl,dc=edu" # logLevel 128(ACL proc) + 32(search filter) + 64(config proc) # loglevel 256(stats log connections/operations/results) + 8 (connection mamangement) #loglevel 288 loglevel 64 allow bind_v2 #modulepath /opt/openldap-2.3.39/libexec/openldap moduleload /opt/openldap-2.3.39/lib/smbk5pwd.la pidfile /opt/openldap-2.3.39/var/run/slapd.pid argsfile /opt/openldap-2.3.39/var/run/slapd.args password-hash {CLEARTEXT} {SSHA} {CRYPT} ####################################################################### # ldbm and/or bdb database definitions ####################################################################### database hdb suffix "dc=mbl,dc=edu" rootdn "cn=admin,ou=users,dc=mbl,dc=edu" rootpw "secret" directory /opt/openldap-2.3.39/var/openldap-data syncrepl rid=111 provider=ldaps://mblauth01.mbl.edu:636 type=refreshAndPersist interval=00:00:01:00 scope sub searchbase="dc=mbl,dc=edu" bindmethod=simple updatedn="uid=syncrepl,ou=Users,dc=mbl,dc=edu" binddn="uid=syncrepl,ou=Users,dc=mbl,dc=edu" credentials=secret updateref ldaps://mblauth01.mbl.edu:636 index objectClass eq index cn pres,sub,eq index sn pres,sub,eq index givenName pres,sub,eq index uid pres,sub,eq index sambaPrimaryGroupSID eq index sambaSID eq index sambaDomainName eq index uidnumber eq index gidNumber eq index sambaHomePath eq index entryUUID eq index automountinformation eq index proxNumber eq index krb5PrincipalName,krb5PrincipalRealm eq index memberUid eq index default sub limits dn.exact="uid=Devicemgr,ou=users,dc=mbl,dc=edu" size=unlimited time=unlimited limits dn.exact="uid=syncrepl,ou=users,dc=mbl,dc=edu" size=unlimited time=unlimited limits dn.exact="uid=onecard,ou=users,dc=mbl,dc=edu" size=unlimited time=unlimited access to dn.subtree="ou=users,dc=mbl,dc=edu" attrs=userPassword,sambaNTPassword,sambaLMPassword,proxNumber,employeeNumber by self read by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by * none access to dn.subtree="ou=users,dc=mbl,dc=edu" attrs=krb5key,krb5EncryptionType,krb5PasswordEnd,krb5KeyVersionNumber,krb5ValidEnd by sockurl.exact=ldapi:/// write by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by self read by * none access to dn.subtree="ou=Groups,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by users read by * none access to dn.subtree="ou=Devices,ou=Network,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by group.exact="cn=mac_admins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by self read by * none access to dn.subtree="ou=Servers,ou=Network,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by self read by * none access to dn.subtree="ou=Computers,ou=Network,dc=mbl,dc=edu" by sockurl.exact=ldapi:/// write by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by dn="uid=search,ou=users,dc=mbl,dc=edu" read by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by anonymous auth by self read by * none access to * by sockurl.exact=ldapi:/// write by self read by dn="cn=proxy,ou=users,dc=mbl,dc=edu" read by dn="uid=syncrepl,ou=users,dc=mbl,dc=edu" write by group.exact="cn=sysadmins,ou=SystemGroups,ou=Groups,dc=mbl,dc=edu" read by users read by * none TLSCipherSuite HIGH:MEDIUM:LOW:+SSLv2+TLSv1 # CA cert file TLSCACertificateFile /opt/openldap-2.3.39/etc/openldap/cacert.pem # Signed cert file TLSCertificateFile /opt/openldap-2.3.39/etc/openldap/newcert.pem # Private key TLSCertificateKeyFile /opt/openldap-2.3.39/etc/openldap/newkey.pem -- Kent L. Nasveschuk Systems Administrator Marine Biological Laboratory 7 MBL Street Woods Hole, MA 02543 Tel. (508) 289-7263

2 1

Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry 04 Dec '07

04 Dec '07

<quote who="Pierangelo Masarati"> > Quanah Gibson-Mount wrote: > >>> I'm confused here. Is it a 2.4 change? >> >> Must be, and seems to be a really odd requirement to me. Why does the >> consumer need to know about it? Why should it be required to load the >> accesslog module? > > As i said, when the __producer__ is configured with the > slapo-accesslog(5) overlay, gets the the auditContext operational > attribute set in the database's context entry. This may be useful to be > able to determine what log context is logging modifications to that > context. As soon as I added accesslog.la to my olcModuleLoad in cn=config, replication started again. I also see in auditlog.ldif (currently testing slapo-auditlog for docs): auditContext: cn=accesslog liek you said above. > As a side effect, syncrepl replicates this attribute as well in the > __consumer__. However, if this attribute is not defined in the > __consumer__'s schema, odd things could happen. i.e. replication stops and is broken ;-) > > So, the only reason to have slapo-accesslog(5) built and loaded **BUT > NOT INSTANTIATED** on the __consumer__ (doesn't sound such strikingly > resource intensive a requirement) is to have this attribute defined in > the schema. Yup, proved this by just loading the module, not using is via "overlay accesslog" etc. > If this sounds so unreasonable, please suggest (and code) a > better strategy. I'm open to everything (including zapping auditContext > at all, unless anyone out there finds it useful and is actively using it). Not unreasonable, just *totally* undocumented. It is, IMHO, a major missing part in the "Changes Since last version" section in the Admin Guide. It's not even in *any* man pages in HEAD. So Syncrepl won't work in 2.4 on any consumer, where the provider has accesslog enabled, i.e. delta-syncrepl. Much appreciated for the feedback Ando. Time for me to get writing ;-) Gavin. > > p. > > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > --------------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Email: pierangelo.masarati(a)sys-net.it > --------------------------------------- > > >

3 3

ldap queries rewriting
by Guillaume Rousse 04 Dec '07

04 Dec '07

Hello list. We have a copier here with a scan-to-mail feature allowing to use LDAP for extracting list of email adresses for users. Unfortunatly, the full user list is retrieved, splitted in groups according to first letter of their email adress, but any entries over 100 in a group are excluded from selection. As we have 120 entries in the A-E group, we have excluded 20 users... As copiers are usually department specific, filtering queries by group membership would allow us to workaround the issue. Unfortunatly, the copier doesn't allow to set up a filter :( Is this possible to do some kind of server-side query rewriting, as mod_rewrite does for apache ? I initially thought of setting up a dynamic group, but this would create a single entry with multiple mail attribute, whereas the copier expect a list of entries with single mail attribute (didn't tested it tough). -- Guillaume Rousse Moyens Informatiques - INRIA Futurs Tel: 01 69 35 69 62

1 0

Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry 04 Dec '07

04 Dec '07

> So, the only reason to have slapo-accesslog(5) built and loaded **BUT > NOT INSTANTIATED** on the __consumer__ (doesn't sound such strikingly > resource intensive a requirement) is to have this attribute defined in > the schema. If this sounds so unreasonable, please suggest (and code) a > better strategy. I'm open to everything (including zapping auditContext > at all, unless anyone out there finds it useful and is actively using it). Here's a question for you ;-) How can test043-delta-syncrepl pass, when there is no accesslog module loaded in slapd-deltasync-slave.conf? Confused again... Gavin.

1 0

ppolicy + slapcat = ldif vulnerability?
by Scott Classen 04 Dec '07

04 Dec '07

I'm not sure if this is truly a vulnerability, but I thought I'd put it out there for discussion. openldap 2.4.6 bdb backend ppolicy overlay I have set up so a default ppolicy such that 3 old passwords are stored in a users pwdHistory attribute. When I back up the bdb database via slapcat -l backup.ldif the userPassword field looks to be Base64 hashed. userPassword:: e1NTSEF9VWFTNDNVDRWEx1QzEyWjASGVWc0VZHRNTmt4M1c= but the passwd history leaves the passwd hashes visible. pwdHistory: 20071203220105Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}wAuvjfMkMyKKHcMV1Tg7qiG0x4 Obviously these backup LDIF files are keep as secure as possible, and these are OLD passwds, but should the pwdHistory attribute also be hashed when being slapcated? Scott

4 5

multiple password policies?
by R.B. 04 Dec '07

04 Dec '07

Hi; After reading some ppolicy HOWTOs, I've seen the following line in the slapd.conf file to assign a default password policy to users. slapd.conf file contains: `ppolicy_default "cn=default,ou=policies,dc=example,dc=com"` So I imagine this is used as the default policy for all users since it's defined globally. If I have several OUs that define users, groups, etc… how would I implement a password policy per user/group? For my setup, I would conceivably have: cn=swa-ppolicy,ou=ppolicies,dc=example,dc=com and cn=pse-ppolicy,ou=ppolicies,dc=example,dc=com ...and so on as I need policies in my directory. How can I apply these per group or user? Would I add a field to my posix[User|Group] schema? Thanks! Rafael

3 2

Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry 04 Dec '07

04 Dec '07

<quote who="Pierangelo Masarati"> > Gavin Henry wrote: >> <quote who="Aaron Richton"> >>> In the spirit of starting with the obvious, do you find auditContext >>> under >>> cn=Subschema? >> >> I'll check ;-) >> >> But why would this attribute get into the normal data dir? > > that attribute is added to the producer to provide a pointer to the > database that contains the log. The attributeType itself is defined by > slapo-accesslog(5), so the overlay should be present (but does not need > to be instantiated; just compiled in or, if built as module, loaded) in > the consumer in order to have that attribute defined. > I forgot say this happened when I added auditlog to the consumer via cn=config. Will investigate more soon.

1 0

Re: 2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry 04 Dec '07

04 Dec '07

<quote who="Aaron Richton"> > In the spirit of starting with the obvious, do you find auditContext under > cn=Subschema? I'll check ;-) But why would this attribute get into the normal data dir? > > On Mon, 3 Dec 2007, Gavin Henry wrote: > >> Hi All, >> >> I blitzed my consumer to test something, and now I'm seeing in its logs: >> >> syncrepl_message_to_entry: rid=000 mods check (auditContext: attribute >> type undefined) >> >> I don't have an accesslog on the consumer, only auditlog for testing so >> I >> can document it. >> >> Any ideas? >> >> Gavin. >> >> -- >> Kind Regards, >> >> Gavin Henry. >> Managing Director. >> >> T +44 (0) 1224 279484 >> M +44 (0) 7930 323266 >> F +44 (0) 1224 824887 >> E ghenry(a)suretecsystems.com >> >> Open Source. Open Solutions(tm). >> >> http://www.suretecsystems.com/ >> >> >> >

2 1

2.4.6 prov/con, delta-syncrepl and auditContext
by Gavin Henry 04 Dec '07

04 Dec '07

Hi All, I blitzed my consumer to test something, and now I'm seeing in its logs: syncrepl_message_to_entry: rid=000 mods check (auditContext: attribute type undefined) I don't have an accesslog on the consumer, only auditlog for testing so I can document it. Any ideas? Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software