openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

ldapadd: invalid format (line 5) entry for LDAP replication
by Brajabasi Padhy 09 Apr '12

09 Apr '12

Hello Sir, I'm trying to set up a LDAP provider server, but facing problime with folowing command sudo ldapadd -Y EXTERNAL -H ldapi:/// -f provider_sync.ldif I followed all steps provided in th following link, but still failing. https://help.ubuntu.com/10.04/serverguide/C/openldap-server.html I'm getting this error ldapadd: invalid format (line 5) entry: "olcDatabase={1}hdb,cn=config" Please help me if possible. The provider_sync.ldif file copied from the above link. Thnaks for your support. Brajabasi

1 0

Replication and user password change
by Jacques Foucry 06 Apr '12

06 Apr '12

Hello the list, I'm new here, new at OpenLDAP and I have an issue. I've search for many time now an explanation but I saw nothing. Here is my problem. I ran a OpenLDAP server on a Debian VM # slapd -V @(#) $OpenLDAP: slapd 2.4.11 (Jul 23 2010 21:37:26) $ @barber:/build/buildd-openldap_2.4.11-1+lenny2-amd64-WJ2jlD/openldap-2.4.11/debian/build/servers/slapd I have many direct client (desktop computer who query the ldap server) and everything work well. I made this ACL on slapd.conf to allow users to change there password: access to attrs=userPassword,shadowLastChange by self write by dn="cn=syncuser,dc=example,dc=com" read by anonymous auth by * none access to * by self write by * read And it works fine. These are the only ACL I have. I also have 2 replications of this LDAP Server. syncrepl rid=002 provider=ldaps://ldap.example.com type=refreshOnly interval=00:01:00:00 retry="60 10 300 +" filter="(objectClass=*)" scope=sub attrs="*" bindmethod=simple schemachecking=off searchbase="dc=example,dc=com" binddn="cn=syncuser,dc=example,dc=com" credentials=youdonthavetoknow tls_reqcert=never The replications work well to and user can connect to those replication computer (I don't have client of those replication). But the trouble is when a user, connected to these replication try to change his password: % passwd Enter login(LDAP) password: New password: Re-enter new password: LDAP password information update failed: Strong(er) authentication required modifications require authentication passwd: Permission denied passwd: password unchanged In the /var/log/auth.log file I found: Apr 4 16:10:45 ovhstorage sshd[22056]: pam_unix(sshd:account): password for user test will expire in 4 days Apr 4 16:10:45 ovhstorage sshd[22056]: Accepted publickey for test from 88.162.182.86 port 49955 ssh2 Apr 4 16:10:45 ovhstorage sshd[22056]: pam_unix(sshd:session): session opened for user test by (uid=0) Apr 4 16:10:48 ovhstorage passwd[22064]: pam_unix(passwd:chauthtok): user "test" does not exist in /etc/passwd Apr 4 16:10:55 ovhstorage passwd[22064]: pam_unix(passwd:chauthtok): user "test" does not exist in /etc/passwd I know that modification must be done on the master server,but how can I send modifications to the master. Did I have to use "referrals"? Thanks in advance for giving the correct pointers. Best regards Jacques Foucry

3 3

Re: 2.4.30 - libldap & libldap_r do not coexist
by Amol Kulkarni 06 Apr '12

06 Apr '12

I'm experiencing the following problem on CentOS6 - although I've not tested on other Os'es. On the same machine I've tested following combinations of client & server versions : Client=2.4.23, Server=2.4.30, Crash=No Client=2.4.30, Server=2.4.23, Crash=Yes So I believe the problem lies in 2.4.30 client libraries which I have compiled. However I'm not able to find something from Changelog related to this. I'll now gdb my program and see if I get anything. Till then does anybody have any idea abt the prb? Thanks, Amol. ----- Original Message ----- From: Amol Kulkarni Sent: 03/24/12 04:27 PM To: Openldap-technical Subject: 2.4.30 - libldap & libldap_r do not coexist Hi, I've a program which links to both libldap & libldap_r dynamically. I've been running this program with openldap 2.4.23 without any problem. But when I upgraded to openldap 2.4.30, the program crashes with segfault. The crash occurs at the end when the program is closing connections. I googled and found that libldap & libldap_r should not be used in same process space bcos they one is non-threadsafe and other is threadsafe and they have same symbols. It is difficult for me to solve the problem by changing my compile configuration bcos my program loads 2 third party libraries which load these different versions of ldaplibraries. One solution for me is to make a soft link from libldap to libldap_r, i.e make everyone use the threadsafe library. Would it be create any problems ? Also, can anyone tell why I did not face the problem in 2.4.23 - I mean is there any compile time setting in openldap for this - which I've missed in 2.4.30 ? Thanks and Regards, Amol Kulkarni.

2 1

LDAP entries missing from search results depending on search base.
by Brandon Hume 05 Apr '12

05 Apr '12

I have a large number of mail aliases stored in LDAP used by sendmail. They're stored off by themselves as opposed to hung off the user objects, so that the mail servers can have their own LDAP replicas containing only a portion of the tree rather than all the user objects as well. An example entry would be thus: dn: cn=broken2,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA objectClass: top objectClass: applicationProcess objectClass: inetLocalMailRecipient cn: broken2 mailRoutingAddress: broken2(a)dal.ca mailLocalAddress: broken2(a)imap.dal.ca However, this entry will not show up in searches, depending on what I use as a search base: A successful search looks like: $ /opt/csw/bin/ldapsearch -x -W -D cn=noc,dc=dal,dc=ca -h kil-ds-3.its.dal.ca -b dc=dal,dc=ca -LLL -s sub '(cn=broken2)' dn Enter LDAP Password: dn: cn=broken2,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA $ However, if I change *only* the search base: $ /opt/csw/bin/ldapsearch -x -W -D cn=noc,dc=dal,dc=ca -h kil-ds-3.its.dal.ca -b cn=services,dc=dal,dc=ca -LLL -s sub '(cn=broken2)' dn Enter LDAP Password: $ A base of cn=Mailmaps,cn=Services,dc=DAL,dc=CA likewise doesn't work, but the entry appears again if I use cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA. This server is running 2.4.30 built with BerkeleyDB 5.3.15. The backend I'm using is HDB. I've *completely* removed any ACLs I had defined and it made no difference... not that I expected it to, since cn=noc,dc=dal,dc=ca is the rootDN. I thought I might have been running into a limit of number of objects inside a container (there's about 123k entries under cn=dal) so I tried dumping the DIT, and moving everything into subcontainers based on first character of the alias (cn=a,cn=dal ; cn=b,cn=dal and so on) which made sure there was no container with more than 10k objects... it still made no difference. I've run the server with olcLogLevel=Any, and I see the following difference in the syslog: A "good" search: Apr 4 16:12:43 kil-ds-3 slapd[29544]: conn=1035 op=1 SRCH base="dc=dal,dc=ca" scope=2 deref=0 filter="(cn=broken2)" Apr 4 16:12:43 kil-ds-3 slapd[29544]: conn=1035 op=1 SRCH attr=dn Apr 4 16:12:43 kil-ds-3 slapd[29544]: => hdb_search Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_dn2entry("dc=dal,dc=ca") Apr 4 16:12:43 kil-ds-3 slapd[29544]: => access_allowed: search access to "dc=DAL,dc=CA" "entry" requested Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= root access granted Apr 4 16:12:43 kil-ds-3 slapd[29544]: => access_allowed: search access granted by manage(=mwrscxd) Apr 4 16:12:43 kil-ds-3 slapd[29544]: search_candidates: base="dc=dal,dc=ca" (0x00000001) scope=2 Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: activity on 1 descriptor Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: activity on: Apr 4 16:12:43 kil-ds-3 slapd[29544]: Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=7 active_threads=0 tvp=zero Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=8 active_threads=0 tvp=zero Apr 4 16:12:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=9 active_threads=0 tvp=zero Apr 4 16:12:43 kil-ds-3 slapd[29544]: => hdb_dn2idl("dc=dal,dc=ca") Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011AND Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa0 Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011OR Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa1 Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011EQUALITY Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates (objectClass) Apr 4 16:12:43 kil-ds-3 slapd[29544]: => key_read Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [b49d1940] Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_index_read: failed (-30988) Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:12:43 kil-ds-3 slapd[29544]: #011EQUALITY Apr 4 16:12:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates (cn) Apr 4 16:12:43 kil-ds-3 slapd[29544]: => key_read Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [2714190a] Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_index_read 1 candidates Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates: id=1, first=338261, last=338261 Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=1 first=338261 last=338261 Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=1 first=338261 last=338261 Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=1 first=338261 last=338261 Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=1 first=338261 last=338261 Apr 4 16:12:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=1 first=338261 last=338261 Apr 4 16:12:43 kil-ds-3 slapd[29544]: bdb_search_candidates: id=1 first=338261 last=338261 Apr 4 16:12:43 kil-ds-3 slapd[29544]: => test_filter Apr 4 16:12:43 kil-ds-3 slapd[29544]: EQUALITY Apr 4 16:12:43 kil-ds-3 slapd[29544]: => access_allowed: search access to "cn=broken2,cn=b,cn=dal,cn=Mailmaps,cn=Services,dc=DAL,dc=CA" "cn" requested And a "bad" search: Apr 4 16:13:43 kil-ds-3 slapd[29544]: conn=1036 op=1 SRCH base="cn=services,dc=dal,dc=ca" scope=2 deref=0 filter="(cn=broken2)" Apr 4 16:13:43 kil-ds-3 slapd[29544]: conn=1036 op=1 SRCH attr=dn Apr 4 16:13:43 kil-ds-3 slapd[29544]: => hdb_search Apr 4 16:13:43 kil-ds-3 slapd[29544]: bdb_dn2entry("cn=services,dc=dal,dc=ca") Apr 4 16:13:43 kil-ds-3 slapd[29544]: => access_allowed: search access to "cn=Services,dc=DAL,dc=CA" "entry" requested Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= root access granted Apr 4 16:13:43 kil-ds-3 slapd[29544]: => access_allowed: search access granted by manage(=mwrscxd) Apr 4 16:13:43 kil-ds-3 slapd[29544]: search_candidates: base="cn=services,dc=dal,dc=ca" (0x00000003) scope=2 Apr 4 16:13:43 kil-ds-3 slapd[29544]: => hdb_dn2idl("cn=services,dc=dal,dc=ca") Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: activity on 1 descriptor Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: activity on: Apr 4 16:13:43 kil-ds-3 slapd[29544]: Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=7 active_threads=0 tvp=zero Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=8 active_threads=0 tvp=zero Apr 4 16:13:43 kil-ds-3 slapd[29544]: daemon: epoll: listen=9 active_threads=0 tvp=zero Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011AND Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa0 Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011OR Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_list_candidates 0xa1 Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011EQUALITY Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates (objectClass) Apr 4 16:13:43 kil-ds-3 slapd[29544]: => key_read Apr 4 16:13:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [b49d1940] Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_index_read: failed (-30988) Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates: id=0, first=0, last=0 Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=0 first=0 last=0 Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_filter_candidates Apr 4 16:13:43 kil-ds-3 slapd[29544]: #011EQUALITY Apr 4 16:13:43 kil-ds-3 slapd[29544]: => bdb_equality_candidates (cn) Apr 4 16:13:43 kil-ds-3 slapd[29544]: => key_read Apr 4 16:13:43 kil-ds-3 slapd[29544]: bdb_idl_fetch_key: [2714190a] Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_index_read 1 candidates Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_equality_candidates: id=1, first=338261, last=338261 Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=1 first=338261 last=338261 Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=1 first=338261 last=338261 Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=1 first=338261 last=338261 Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_list_candidates: id=0 first=3 last=0 Apr 4 16:13:43 kil-ds-3 slapd[29544]: <= bdb_filter_candidates: id=0 first=3 last=0 Apr 4 16:13:43 kil-ds-3 slapd[29544]: bdb_search_candidates: id=0 first=3 last=0 Apr 4 16:13:43 kil-ds-3 slapd[29544]: hdb_search: no candidates Apr 4 16:13:43 kil-ds-3 slapd[29544]: send_ldap_result: conn=1036 op=1 p=3 Apr 4 16:13:43 kil-ds-3 slapd[29544]: send_ldap_result: err=0 matched="" text="" Apr 4 16:13:43 kil-ds-3 slapd[29544]: send_ldap_response: msgid=2 tag=101 err=0 Apr 4 16:13:43 kil-ds-3 slapd[29544]: conn=1036 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= Notable is hdb_search finding no candidates. Is there anything obviously wrong, here?

4 14

db in shadow context without replication
by Julien Soula 05 Apr '12

05 Apr '12

hello, I have a problem with a cancelation of replication of cn=config. I configured replication of cn=config in slapd.d (without slapd.conf) and I wanted to stop it. First one, I didn't see how to cancel replication in cn=config otherwise that deleting olcSyncRepl attribute directly in slapd.d files since database was in shadow context. Is there a proper way ? So I stopped slapd and deleted olcSyncRepl attribute and restarted it. But when I commited change, it failed with error : "shadow context without update referral" (there is no more olcSyncRepl in config) ! I tried to enable olcMirrorMode (directly in files again) but slapd crashed at start saying that the database was not in shadow context ! I cannot explain this behaviour. How the server determine that a database is in shadow context or not ? Is there a cache somewhere ? Sincerly, -- Julien << Vous n'avez rien a dire... Parlons-en! >>

1 1

Re: AD proxy in OpenLDAP
by Christopher O'Kelly 04 Apr '12

04 Apr '12

(feeling a tad silly, now that I have discovered I was not replying to the actual mailing list but to single people.) OK so I have managed to get both the ldap and hdb databases to coexist, mostly through copying code straight from the ldapglue test in the OpenLDAP build files. The ldif file I use now for my backend is as follows - dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/ldap olcModuleload: back_hdb olcModuleload: back_ldap dn: olcDatabase={1}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {1}ldap olcSuffix: ou=internal,dc=companyname,dc=local olcSubordinate: TRUE olcDbURI: "ldap://companyname.local" olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE dn: olcDatabase={2}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {2}hdb olcSuffix: dc=companyname,dc=local olcLastMod: TRUE olcRootDN: cn=admin,dc=companyname,dc=local olcRootPW: {SSHA}hashed password olcDbDirectory: /var/lib/ldap olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbCheckpoint: 512 30 olcAccess: to attrs=userPassword by dn="cn=admin,dc=minecorp,dc=local" write by anonymous auth by self write by * none olcAccess: to attrs=shadowLastChange by self write by * read olcAccess: to dn.base="" by * read olcAccess: to * by dn="cn=admin,dc=companyname,dc=local" write by * read I can search dc=companyname,dc=local fine, I see the users in this tree and the Internal OU. However I do not see any of the users from the AD linked to by this database. I know I can ldap search it from the server and get results, so I believe that either I need to construct my search differently or it is an authentication issue. As I read it, I need to use idassert-bind, specifying a user from AD with read access, and that user will be used to search AD. I have a few questions leading from this - The first is: does anyone know the syntax for idassert-bind as it applies to ldif files to be ldapadded to the RTC? As I read it, if it were slapd.conf I would want - idassert-bind bindmethod=simple binddn="cn=proxy,ou=service accounts,ou=users,dc=companyname,dc=local" credentials="password" mode=self but I am unsure how to structure this for RTC. The second is - am I correct in thinking that, once this is all working, a search with (objectclass=*) on the dc=companyname,dc=local should return all the users in that branch as well as all the users in AD? Or will I need to craft my search differently to deal with the proxy? The third is also just a confirmation - is idassert-bind meant for what I think it is? Should it contain a user not in the local DSA but in the one I am proxying to? Or have I misread?

1 0

RE: ppolicy master/slave issue
by Chris Jacobs 04 Apr '12

04 Apr '12

Nope - I merely left out the chain directives. Given the choice between "forward ppolicy updates" or "allow users to change their passwords anywhere", we went with the former. We never identified how to get them to /both/ work and require actual user authentication. This is ok in our environment - and as it turns out we kind of like this limitation. Our corp environment authenticates off the master servers and we simply tell people to use a corp servers to change their password. We don't have any users (besides myself) whose desktop's authenticate from our OpenLDAP infrastructure - it's only our servers. Here's the bits we simply removed from the conf (from the thread you're quoting, the rest is largely the same): chain-uri ldaps://ldap-vip.corp.example.net/ chain-rebind-as-user TRUE chain-idassert-bind bindmethod="simple" binddn="cn=root,dc=example,dc=net" credentials="secret" mode="self" chain-tls ldaps chain-return-error TRUE Someone else hopped onto the thread indicating they had the same problems - but no one ever chimed in with "this is what's going on" or "this is what you're doing wrong". Such is free community support. :) We're now using the RHEL6/CentOS6 2.4.23 supplied packages (nearly a sin in this mailing list, but everything is working fine for us) but haven't approached attempting this again as we're used to this limitation. Of course, that wouldn't be the case if user desktops authenticated from local slave ldap servers, but we're not in that situation and really, we've a lot of other fish in the frying pan. Good luck! - chris From: Limb, Jong (VDSS) [mailto:Jong.Limb@dss.virginia.gov] Sent: Wednesday, April 04, 2012 7:45 AM To: Chris Jacobs Subject: ppolicy master/slave issue Were you ever able to figure out why the authentication against a slave works regardless of the password as you describe below? I am having the exact same problem. Thanks. Jong Limb Division of Information Systems Virginia Department of Social Services 804-726-7823 Hello again, I'm having an odd issue with ppolicy and my master/slave config. First, my goals General use: Slave handles all reads locally. Writes get forwarded to the master by the slave. Password policy: When password failures happen on clients using slave ldap servers, the failures, etc, get passed to the master to get replicated to the slaves. I understand this would be done using the ppolicy option: ppolicy_forward_updates Authentication: Actually authenticate (more later). To the problem: --------------- When I leave the section in the chain bit of SLAVE slapd.conf below marked by lines intact (which bind as root): * ppolicy_forward_updates seems to work great - the master shows matching "pwdFailureTime" attributes. * Regardless of password entered, you get a shell. User/bad password = get a shell! This being a problem should be obvious. I suspect that's due to the chain overlay section... ________________________________ This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system.

1 0

openldap proxy to AD
by Induni, Marco 04 Apr '12

04 Apr '12

Hi all, I'm building an openldap proxy to an AD server and adding a little of "intelligence" based on the client request. Unfortunately the client/program asking information about an account, need to be setup with user and password. There is a way to let the proxy "ignore" this user and password and instead just use the ones specified on the slapd.conf file ? Or setup fake credential somewhere ? In detail, query are something like: ldapsearch -x -h openldap-proxy -w "secret" -D "CN=MGRADREAD05,CN=MGR,DC=example,DC=com" -b "dc=pmm,dc=int" userPrincipalName=TST-USER10 but I need that the proxy exclude the "-w "secret" -D "CN=MGRADREAD05,CN=MGR,DC=example,DC=com" part, and use the one on the conf file. In fact if I do a query like: ldapsearch -x -h openldap-proxy -w "secret" -D "CN=MGRADREAD05,CN=MGR,DC=example,DC=com" -b "dc=pmm,dc=int" userPrincipalName=TST-USER10 it works. Here the slapd.conf database meta suffix "dc=pmm,dc=int" uri "ldap://10.10.10.1/dc=pmm,dc=int" suffixmassage "dc=pmm,dc=int" "dc=media,dc=int" rewriteContext searchFilter rewriteRule "userPrincipalName=(.*)(a)rtsi.ch" "userPrincipalName=%1(a)rsi.ch" ":" rewriteRule "sAMAccountName=([:alnum:])" "userPrincipalName=%1(a)rtr.ch" ":" idassert-bind bindmethod=simple binddn="CN=svc-adread05,CN=AdminAccounts,OU=RSI,OU=Units,DC=media,DC=int " credentials="Comano2012" mode=self idassert-authzFrom "dn.regex:.*" Any idea ? Many thank's and best regards. Marco ****************************************************** Visit: http://www.rsi.ch This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmaster(a)rsi.ch

2 2

Convert *.schema to *.ldif
by Francis Swasey 04 Apr '12

04 Apr '12

I don't see any description in the admin guide about how to convert a *.schema file into a *.ldif file. Google tells me that most people are using slaptest with the -F and -f parameters with a specially crafted slapd.conf file. As the person who is responsible for a *.schema file and develops it not on a machine that has the openldap server software installed, that process is not anything I'm interested in. Looks like it should be a fairly simple set of transformations. Looking at the *.schema and *.ldif that are provided with the openldap source - I am left wondering how they were created, since they have comments, they were obviously not created via the slaptest -F <x> -f <y> method. I would like to programatically do this -- my ability to vi two files and make identical changes has been known to be fallable! I found the fusiondirectory-schema2ldif perl script - but it is not complete and silently drops keywords it doesn't like which is a really nasty coding style generating garbage from quality schemas. Suggestions? Code examples? Thanks, -- Frank Swasey | http://www.uvm.edu/~fcs Sr Systems Administrator | Always remember: You are UNIQUE, University of Vermont | just like everyone else. "I am not young enough to know everything." - Oscar Wilde (1854-1900)

6 7

Password expiration
by Collins, Cris L. 04 Apr '12

04 Apr '12

I am running OpenLDAP as packaged for CentOS 5 and having problems with password expiration. Users are being told every time they login that their password has expired and to change their password. When ShadowMax is changed to 99999 their passwords are not expiring. The preferable setting is 90 days. ShadowLastChange is updating to the correct date when they input a new password. Thank you for you time and input as to why this might be occurring.

4 3

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical