March 2012 - openldap-technical

by stefano

Hi, i've a question. am configuring the ACLs in slapd.conf. is it necessary to specify the Administrator DN in the "who" field? ex: access to attrs=userPassword by dn="cn=Manager,dc=example,dc=com" Do i have to specify it or the administrator has the access right to every attribute?

11 years, 2 months

3
3
0 / 0

Re: ACLs for children entry

by Hallvard Breien Furuseth

On Thu, 22 Mar 2012 14:22:45 +0100, Natalia <nata.cs2(a)gmail.com> wrote: > I have the following tree structure in LDAP: > ou=people,dc=example,dc=com > uid=user1,ou=people,dc=example,dc=com > > cn=child1,uid=user1,ou=people,dc=example,dc=com > cn=child2,uid=user1,ou=people,dc=example,dc=com > uid=user2,ou=people,dc=example,dc=com > .. > > I would like to make access in such a way: if fathers account > (uid=user1,ou=people,dc=example,dc=com) is inactivated > (description=inaktiv), all children become inaccessible. Something like this, I think. Untested, sorry. to dn.regex=",(uid=[^,]+,ou=people,dc=example,dc=com)$" by set.expand="[$1]/description & inaktiv" none by group.exact="cn=ldapadmin,dc=example,dc=com" tls_ssf=128 sasl_ssf=56 write by * +0 break I.e. access to: any children of an uid=... entry. 1. Look up 'description' in entry $1 ("uid=...), and refuse access if it matches 'inaktiv'. 2. For other entries, ldap admin over TLS+SASL gets full access. 3. For everyone else, skip this access statement and go on to check the following access 'to' statements. Drop the regexps' initial "," to also control the uid=... entry. Swap (1) and (2) to also give admin access to inactive subtrees. Replace (3) with e.g. 'by * read' to instead give others read access. > I have tried with this, but it has not functioned: > to dn.regex="uid=([^,]+),ou=people,dc=example,dc=com" > filter="(description=inaktiv)" attrs=children > by group.exact="cn=ldapadmin,dc=example,dc=com" tls_ssf=128 > sasl_ssf=56 write > by * none That's not what "()" in regexps, filter, and children mean. See man slapd.access. The access syntax tries to make sensible access statements readable, but that doesn't mean any readable access statement is sensible:-) This is what your access statement means: When accessing e.g. the entry "cn=child1,...", your dn.regex is checked against the DN, and matches. But the filter is checked against the cn=child1 entry, not against a parent entry. That does not match. Nor does attrs=children usually match - that's a pseudo-attribute which Add/Delete/Rename check in the parent entry of the entry being added. So this access statement is skipped, since the 'to' statement normally does not match. If it had matched, you'd then give write access to ldapadmin if they use TLS and SASL. Nobody else would get access. -- Hallvard

11 years, 2 months

2
1
0 / 0

Replicating a translucent database

by David Arroyo

Hello, Does anyone have experience with replicating the "local" part of a translucent proxy? I've gotten into the habit of running redundant pairs for everything. Since translucent uses back-ldap, which sets lastmod off, traditional replication via syncrepl doesn't work. Right now I'm only supporting a directory of about 2000 engineers, so it is feasible to use some combination of slapcat and ldapadd/ldapmodify magic to update a secondary server. I could also slapcat the translucent database and take down the secondary server while the database is rebuilt. One idea I had is to copy the local translucent database to a separate (non-proxy)server every N hours, and have any slaves replicate off of that. However, due to schema checking I cannot simply copy a translucent db to a non-translucent one due to all the glue and missing attributes. I've found the translucent overlay (and openLDAP's flexibility in general) to be a lifesaver. If anyone has any ideas or experience with this particular challenge, I'd love to hear about it. Cheers, David Arroyo

11 years, 2 months

1
0
0 / 0

Re: Root not allowed to login

by SYeen Su

Hello Chris, THis is what I got when I tried logging in from the KVM console/ILOM: login: pam_ldap: error trying to bind as user "uid=root,ou=People,dc=synamatix,dc=com" (Invalid credentials) Mar 23 10:44:40 mgrc-prod-sdb9 login: ROOT LOGIN ON tty1 It will alaways try to bind as user "uid=root" even though root is local. On Fri, Mar 23, 2012 at 10:37 AM, Chris Jacobs <Chris.Jacobs(a)apollogrp.edu>wrote: > What do your logs say when root tries to login? > > > Chris Jacobs > Systems Administrator, Technology Services Group > > Apollo Group | Apollo Marketing & Product Development | Aptimus, Inc. > 1501 4th Ave | Suite 2500 | Seattle, WA 98101 > direct 206.839.8245 | cell 206.601.3256 | Fax 206.644.0628 > email: chris.jacobs(a)apollogrp.edu > > ------------------------------ > *From*: SYeen Su <seauyeen(a)mgrc.com.my> > *To*: Chris Jacobs > *Cc*: mlstarling31(a)hotmail.com <mlstarling31(a)hotmail.com>; > openldap-technical(a)openldap.org <openldap-technical(a)openldap.org> > *Sent*: Thu Mar 22 19:32:07 2012 > > *Subject*: Re: Root not allowed to login > > Hi Chris, > > For testing purpose I disabled the PermitRootLogin to yes temporarily. > Usually it's no and the failure was noticed when the server lost connection > to the ldap server and even root ( that's local) is not able to log in. > Hence, I started investigating what is wrong. Bottomline, via console, root > is not able to log in if there is no network connectivity to ldap and I am > trying to solve this issue because if even root and any othe rlocal users > cannot log in via console, I am not able to check what is wrong with the > network, the only option is to reboot, which is what I'd like to avoid. > > > On Fri, Mar 23, 2012 at 10:14 AM, Chris Jacobs <Chris.Jacobs(a)apollogrp.edu > > wrote: > >> Syeen, >> >> Are you trying to login remotely? Or at the local console? >> >> If remotely, this may be standard behavior as usually PermitRootLogin is >> set to no in /etc/ssh/sshd_config - which I would NOT recommend changing. >> During an outage, local console access would have to be used (via ILO, some >> KVM over IP, etc, solution). >> >> Other than that, everything in your system-auth-ac and nsswitch.conf look >> fine to me. >> >> - chris >> >> >> *Chris Jacobs,** *Jr. Unix System Administrator >> Apollo Group | Apollo Marketing | ITG >> >> 2001 6th Ave, Suite 3200 | Seattle, WA 98121-2522 >> phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 >> >> email: chris.jacobs(a)apollogrp.edu >> >> ------------------------------ >> *From:* SYeen Su [seauyeen(a)mgrc.com.my] >> *Sent:* Thursday, March 22, 2012 7:13 PM >> >> *To:* Chris Jacobs >> *Cc:* mlstarling31(a)hotmail.com; openldap-technical(a)openldap.org >> *Subject:* Re: Root not allowed to login >> >> Hi Chris, >> >> Exactly, all my configuration seems correct as I have compared. Hmm let's >> just say i am not familiar with sssd and to migrate to sssd, I think i >> gotta spend some time studying it. So, i know, i took the easy way out by >> just porting over my previous ldap configuration to RHEL6. >> >> Anyway, my snippets from /etc/nsswitch.conf file as below: >> >> *passwd: files ldap >> shadow: files ldap >> group: files ldap >> * >> It matches yours too, right? If i put the sequence the other way round, >> root practically cannot log in at all! >> >> What else do I need to configure on my client side? I am lost! >> >> On Fri, Mar 23, 2012 at 10:10 AM, Chris Jacobs < >> Chris.Jacobs(a)apollogrp.edu> wrote: >> >>> Again, this isn't an openldap issue, but... >>> >>> Your /etc/pam.d/system-auth-ac file looks fine to me - it matches both >>> our CentOS5 and CentOS6 machines. >>> >>> I looked and was unable to find any attachments or included snippets >>> from your /etc/nsswitch.conf file. >>> >>> On our systems using PADL's pam_ldap, you should have in there: >>> passwd: files ldap >>> shadow: files ldap >>> group: files ldap >>> >>> Digression: I'm a little surprised you're using pam's padl software. >>> Between nss-pam-ldapd and sssd we decided to embrace the apparent future >>> and have successfully moved to sssd for our CentOS 6 boxes. >>> ** This doesn't impact your problem though. ** >>> >>> *Chris Jacobs,** *Jr. Unix System Administrator >>> Apollo Group | Apollo Marketing | ITG >>> >>> 2001 6th Ave, Suite 3200 | Seattle, WA 98121-2522 >>> phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 >>> >>> email: chris.jacobs(a)apollogrp.edu >>> >>> ------------------------------ >>> *From:* SYeen Su [seauyeen(a)mgrc.com.my] >>> *Sent:* Thursday, March 22, 2012 6:22 PM >>> *To:* Chris Jacobs >>> *Cc:* mlstarling31(a)hotmail.com; openldap-technical(a)openldap.org >>> >>> *Subject:* Re: Root not allowed to login >>> >>> Hi Chris, >>> >>> That's what I suspect too but I am not sure how else to tweak my pam and >>> nsswitch files. Do you have any suggestions? Below is my pam.d/system-auth >>> file and my nsswitch file excerpt has been attached previously. >>> >>> #%PAM-1.0 >>> # This file is auto-generated. >>> # User changes will be destroyed the next time authconfig is run. >>> auth required pam_env.so >>> auth sufficient pam_unix.so nullok try_first_pass >>> auth requisite pam_succeed_if.so uid >= 500 quiet >>> auth sufficient pam_ldap.so use_first_pass >>> auth required pam_deny.so >>> >>> account required pam_unix.so broken_shadow >>> account sufficient pam_localuser.so >>> account sufficient pam_succeed_if.so uid < 500 quiet >>> account [default=bad success=ok user_unknown=ignore] pam_ldap.so >>> account required pam_permit.so >>> >>> password requisite pam_cracklib.so try_first_pass retry=3 >>> dcredit=-2 ucredit=-2 lcredit=-2 ocredit=-2 minlen=8 type=strong >>> password sufficient pam_unix.so md5 shadow nullok try_first_pass >>> use_authtok >>> password sufficient pam_ldap.so use_authtok >>> password required pam_deny.so >>> >>> session optional pam_keyinit.so revoke >>> session required pam_limits.so >>> session [success=1 default=ignore] pam_succeed_if.so service in >>> crond quiet use_uid >>> session required pam_unix.so >>> session optional pam_ldap.so >>> >>> Is there anything amiss with my pam file? If you need to have a look at >>> my login and sshd pam file, please tell me so. >>> >>> Thanks a lot. >>> >>> On Fri, Mar 23, 2012 at 9:17 AM, Chris Jacobs < >>> Chris.Jacobs(a)apollogrp.edu> wrote: >>> >>>> The timeouts are how long to wait for ldap to respond. It should >>>> check local (normally via pam) next. >>>> >>>> We have our user's in LDAP and can still login using the local accounts. >>>> >>>> Your issue isn't an LDAP problem, it's a pam/nsswitch/local issue. >>>> >>>> - chris >>>> >>>> Chris Jacobs >>>> Systems Administrator, Technology Services Group >>>> >>>> Apollo Group | Apollo Marketing & Product Development | Aptimus, >>>> Inc. >>>> 1501 4th Ave | Suite 2500 | Seattle, WA 98101 >>>> direct 206.839.8245 | cell 206.601.3256 | Fax 206.644.0628 >>>> email: chris.jacobs(a)apollogrp.edu >>>> >>>> ------------------------------ >>>> *From*: openldap-technical-bounces(a)OpenLDAP.org<openldap-technical-bounces(a)OpenLDAP.org> >>>> >>>> *To*: Michael Starling <mlstarling31(a)hotmail.com> >>>> *Cc*: openldap <openldap-technical(a)openldap.org> >>>> *Sent*: Thu Mar 22 18:10:55 2012 >>>> *Subject*: Re: Root not allowed to login >>>> >>>> Hi Michael, >>>> >>>> I have changed the timelimit and bind_timelimit to 4 but it still >>>> checks with ldap immediately ( I mean when root logs in ). i doubt it has >>>> anything to do with the time because it checks immediately without any >>>> delay. >>>> >>>> On Thu, Mar 22, 2012 at 9:51 PM, Michael Starling < >>>> mlstarling31(a)hotmail.com> wrote: >>>> >>>>> Try setting your timelimt and bind_timelimit to something like a bit >>>>> lower. >>>>> >>>>> timelimit 4 >>>>> >>>>> bind_timelimit 4 >>>>> >>>>> ------------------------------ >>>>> Date: Thu, 22 Mar 2012 17:03:56 +0800 >>>>> Subject: Root not allowed to login >>>>> From: seauyeen(a)mgrc.com.my >>>>> To: openldap-technical(a)openldap.org >>>>> >>>>> >>>>> Hi, >>>>> >>>>> My client is installed with RHEL 6.0 and I am using OpenLDAP 2.4. When >>>>> the box loses connection with the ldap server, even the root cannot log in >>>>> as it tries to bind with the ldap server. This can be seen when I log in >>>>> with root and the message below appears : >>>>> >>>>> sshd: pam_ldap: error trying to bind as user "uid=root, ou=People, >>>>> dc=example,dc=com" (Invalid credentials). >>>>> >>>>> My root user is not even in the ldap database. When connection is >>>>> fine, the message above does not affect the login of root. The login of >>>>> root is only screwed up when the box loses connectivity. >>>>> >>>>> Attached are my pam.d/system-auth file, pam.d/login, pam./dsshd and >>>>> ldap.conf files. >>>>> >>>>> I have been googling around but some either switch to kerberos, or the >>>>> question is left unatttended to. Please help. I can only resort to >>>>> restarting the box whenever this happens. How can I configure the ldap so >>>>> that local users can login when there's no connectivity to ldap server? >>>>> >>>>> Thanks heaps! >>>>> >>>>> -- >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> MGRC - *Sequence. Analyse. Innovate.* >>>>> *Su Seau Yeen >>>>> Manager, IT Operations >>>>> *** >>>>> *Malaysian Genomics Resource Centre Berhad (MGRC)* >>>>> T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | >>>>> www.mgrc.com.my >>>>> ------------------------------ >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> This e-mail is intended only for the use of the individual or >>>>> entity to which it is addressed and may contain confidential and/or >>>>> privileged material. Any review, retransmission, dissemination or other use >>>>> of or taking of any action in reliance upon this information by persons or >>>>> entities other than the intended recipient, is strictly prohibited. If you >>>>> receive this e-mail in error, please contact us immediately by return >>>>> e-mail and delete the original message(s). >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> >>>> >>>> ------------------------------ >>>> MGRC - *Sequence. Analyse. Innovate.* >>>> *Su Seau Yeen >>>> Manager, IT Operations >>>> *** >>>> *Malaysian Genomics Resource Centre Berhad (MGRC)* >>>> T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | >>>> www.mgrc.com.my >>>> ------------------------------ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> This e-mail is intended only for the use of the individual or entity >>>> to which it is addressed and may contain confidential and/or privileged >>>> material. Any review, retransmission, dissemination or other use of or >>>> taking of any action in reliance upon this information by persons or >>>> entities other than the intended recipient, is strictly prohibited. If you >>>> receive this e-mail in error, please contact us immediately by return >>>> e-mail and delete the original message(s). >>>> >>>> ------------------------------ >>>> This message is private and confidential. If you have received it in >>>> error, please notify the sender and remove it from your system. >>>> >>>> >>> >>> >>> -- >>> >>> >>> >>> ------------------------------ >>> MGRC - *Sequence. Analyse. Innovate.* >>> *Su Seau Yeen >>> Manager, IT Operations >>> *** >>> *Malaysian Genomics Resource Centre Berhad (MGRC)* >>> T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | >>> www.mgrc.com.my >>> ------------------------------ >>> >>> >>> >>> >>> >>> >>> >>> This e-mail is intended only for the use of the individual or entity >>> to which it is addressed and may contain confidential and/or privileged >>> material. Any review, retransmission, dissemination or other use of or >>> taking of any action in reliance upon this information by persons or >>> entities other than the intended recipient, is strictly prohibited. If you >>> receive this e-mail in error, please contact us immediately by return >>> e-mail and delete the original message(s). >>> >>> ------------------------------ >>> This message is private and confidential. If you have received it in >>> error, please notify the sender and remove it from your system. >>> >>> >> >> >> -- >> >> >> >> ------------------------------ >> MGRC - *Sequence. Analyse. Innovate.* >> *Su Seau Yeen >> Manager, IT Operations >> *** >> *Malaysian Genomics Resource Centre Berhad (MGRC)* >> T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | >> www.mgrc.com.my >> ------------------------------ >> >> >> >> >> >> >> >> This e-mail is intended only for the use of the individual or entity >> to which it is addressed and may contain confidential and/or privileged >> material. Any review, retransmission, dissemination or other use of or >> taking of any action in reliance upon this information by persons or >> entities other than the intended recipient, is strictly prohibited. If you >> receive this e-mail in error, please contact us immediately by return >> e-mail and delete the original message(s). >> >> ------------------------------ >> This message is private and confidential. If you have received it in >> error, please notify the sender and remove it from your system. >> >> > > > -- > > > > ------------------------------ > MGRC - *Sequence. Analyse. Innovate.* > *Su Seau Yeen > Manager, IT Operations > *** > *Malaysian Genomics Resource Centre Berhad (MGRC)* > T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | > www.mgrc.com.my > ------------------------------ > > > > > > > > This e-mail is intended only for the use of the individual or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of or > taking of any action in reliance upon this information by persons or > entities other than the intended recipient, is strictly prohibited. If you > receive this e-mail in error, please contact us immediately by return > e-mail and delete the original message(s). > > ------------------------------ > This message is private and confidential. If you have received it in > error, please notify the sender and remove it from your system. > > -- ------------------------------ MGRC - *Sequence. Analyse. Innovate.* *Su Seau Yeen Manager, IT Operations ** * *Malaysian Genomics Resource Centre Berhad (MGRC)* T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | www.mgrc.com.my ------------------------------ This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient, is strictly prohibited. If you receive this e-mail in error, please contact us immediately by return e-mail and delete the original message(s).

11 years, 2 months

1
0
0 / 0

Root not allowed to login

by SYeen Su

Hi, My client is installed with RHEL 6.0 and I am using OpenLDAP 2.4. When the box loses connection with the ldap server, even the root cannot log in as it tries to bind with the ldap server. This can be seen when I log in with root and the message below appears : sshd: pam_ldap: error trying to bind as user "uid=root, ou=People, dc=example,dc=com" (Invalid credentials). My root user is not even in the ldap database. When connection is fine, the message above does not affect the login of root. The login of root is only screwed up when the box loses connectivity. Attached are my pam.d/system-auth file, pam.d/login, pam./dsshd and ldap.conf files. I have been googling around but some either switch to kerberos, or the question is left unatttended to. Please help. I can only resort to restarting the box whenever this happens. How can I configure the ldap so that local users can login when there's no connectivity to ldap server? Thanks heaps! -- ------------------------------ MGRC - *Sequence. Analyse. Innovate.* *Su Seau Yeen Manager, IT Operations ** * *Malaysian Genomics Resource Centre Berhad (MGRC)* T: +6 03 2283 1820 | F: +6 03 2282 8102 | M: +6 012 6784642 | www.mgrc.com.my ------------------------------ This e-mail is intended only for the use of the individual or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of or taking of any action in reliance upon this information by persons or entities other than the intended recipient, is strictly prohibited. If you receive this e-mail in error, please contact us immediately by return e-mail and delete the original message(s).

11 years, 2 months

4
10
0 / 0

OPENLDAP & SSL -- FOR FAILOVER

by Borresen, John - 0442 - MITLL

Question: Right now, we have two OpenLDAP servers running in Delta-syncrepl and talking fine. All the clients are connecting to the primary over port 636. The question is on the best (practices) way of getting the secondary server into the certificate without re-hashing all the clients to the failover server's certificate. 1) Should I set up a Wildcard certificate? 2) Should I put both systems in the "subjectAltName" line and create the certifiate, etc? 3) DNS Round-Robin? Not 100% sure in which direction to go. Dave Borresen Solaris/Linux Systems Administrator Surveillance Systems Group MIT Lincoln Laboratory 244 Wood Street Lexington, MA 02420 john.borresen(a)ll.mit.edu

11 years, 2 months

4
3
0 / 0

ACLs for children entry

by Natalia

Hello, I have the following tree structure in LDAP: ou=people,dc=example,dc=com uid=user1,ou=people,dc=example,dc=com cn=child1,uid=user1,ou=people,dc=example,dc=com cn=child2,uid=user1,ou=people,dc=example,dc=com uid=user2,ou=people,dc=example,dc=com .. I would like to make access in such a way: if father's account (uid=user1,ou=people,dc=example,dc=com) is inactivated (description=inaktiv), all children become inaccessible. I have tried with this, but it has not functioned: to dn.regex="uid=([^,]+),ou=people,dc=example,dc=com" filter="(description=inaktiv)" attrs=children by group.exact="cn=ldapadmin,dc=example,dc=com" tls_ssf=128 sasl_ssf=56 write by * none Is it possible to implement such a thing? Thanks in advance for help! Natalia

11 years, 2 months

1
0
0 / 0

RE: openLDAP as a proxy for AD

by Chris O'Kelly

>Thanks Alex for replying, >... >... OK, a days work has led me to discover that while apt-get purge --auto-remove slapd ldap-utils does not actually purge slapd or ldap-utils, but appears to uninstall them and purge all their dependencies. I think this was behind my larger issues with openldap, apt-get purge slapd ldap-utils fixed that for me. I am now circling back around to my original problem. to clarify, there are 2 servers. DC Server - AD set up, internal users and groups and policy etc. All working fine. ubuntu server - OpenLDAP set up, external users usernames and passwords. we need our various web apps to point to this for authentication and return users from either of the DSA's backend of openLDAP currently set up like this (basically straight from a tutorial) - # Load dynamic backend modules dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/ldap olcModuleload: back_hdb olcModuleload: back_ldap # Database settings dn: olcDatabase=hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcSuffix: dc=companyname,dc=local olcDbDirectory: /var/lib/ldap olcRootDN: cn=admin,dc=companyname,dc=local olcRootPW: secret olcDbConfig: set_cachesize 0 2097152 0 olcDbConfig: set_lk_max_objects 1500 olcDbConfig: set_lk_max_locks 1500 olcDbConfig: set_lk_max_lockers 1500 olcDbIndex: objectClass eq olcLastMod: TRUE olcDbCheckpoint: 512 30 olcAccess: to attrs=userPassword by dn="cn=admin,dc=companyname,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 am trying to get the proxy set up at dc=AD,dc=companyname,dc=local. so far my slapd.conf is - # AD server proxy database ldap suffix "dc=AD,dc=companyname,dc=local" uri ldap://companyname.local/ idassert-bind bindmethod=simple binddn="cn=admin,dc=companyname,dc=local" credentials=secret authzID="dn:cn=admin,dc=companyname,dc=local" however on running slaptest I get slapd.conf: line 4: <suffix> invalid DN 21 (Invalid syntax) slaptest: bad configuration directory! I tried suffix with and without the "s to no avail. A side question which neither man slaptest nor google has answered for me thusfar, will slaptest add the configuration to slapd.d or overwrite it? I do totally get that I am basically asking someone to do my job for me here, which is not a habit I like to cultivate but I would be eternally grateful if anyone could just point me in the right direction. I have done enough tech support to be frustrated to be on this side of the RTFM coin but I assure you I have trawled man pages, tutorials and forums before I came here.

11 years, 2 months

1
0
0 / 0

RE: openLDAP as a proxy for AD

by Chris O'Kelly

Thanks Alex for replying, I was rather optimistic about this until I realized I have bigger problems now, I had been putting the subordinate directive in the definition for the back_ldap db, not the normal hdb on openldap OK so I have a whole lot of problems at this point. I believe I have seriously broken something in trying to slaptest or ldapadd a bunch of slapd.conf/ldif files, following various tutorials. Tried to follow your steps this morning but found I was getting - ldap_add: Server is unwilling to perform (53) additional info: no global superior knowledge and more often than not was unable to authenticate, either in CLI or by Apache directory studio. So once again I apt-get purge --auto-remove slapd ldap-utils and installed again, however I found that all the broken configuration I had tried so far was immediately back in /etc/ldap/slapd.d again as soon as I installed. (not the default config which would be in there immediately after install, the big list of faulty databases I had added erroneously before). I had checked and the whole /etc/ldap directory WAS removed during the purge. So I ran the purge again, then ran a find and deleted /var/lib/ldap and /usr/lib/ldap, then installed again. Now, when I tried to start again, following http://doc.ubuntu.com/ubuntu/serverguide/C/openldap-server.html to start with, I can't even get off the starting line! My first step, running sudo ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/ldap/schema/cosine.ldif returns - ldap_add: Other (e.g., implementation specific) error (80) additional info: olcAttributeTypes: Duplicate attributeType: "0.9.2342.19200300.100.1.2" and I get the same response ldapadding pretty much anything, with a different value for attributeType. Again it appears that purging and reinstalling does not get me back to a default installation but I am not sure what else I need to delete. On another note, following your advice, this is essentially what I have boiled my slapd.conf down to (for once I can actually use openLDAP again). Do you see any glaring omissions or obvious errors here? include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema moduleload back_ldap.la moduleload back_hdb.la # Specify first database database hdb suffix "dc=external users,dc=companyname,dc=local" rootdn "cn=admin,dc=companyname,dc=local" rootpw secret directory /var/lib/ldap/ subordinate advertise # Specify other databases database ldap suffix "dc=companyname,dc=local" rootdn "cn=admin,dc=companyname,dc=local" uri ldap://companyname.local/ rebind-as-user TRUE chase-referrals TRUE

11 years, 2 months

1
0
0 / 0

OpenLDAP client and SSL handshaek

by Jon Dufresne

Hi, I am using OpenLDAP as a client to connect to a 3rd party Oracle Internet Directory 10g. After recent updates, I have been unable to successfully bind with the LDAP server. I believe this is an error with the SSL handshake because the following command will not negotiate an SSL protocol: $ openssl s_client -connect HOST:636 ... Failure While adding the -no_tls1 flag will: $ openssl s_client -connect HOST:636 -no_tls1 ... Success When I attempt to connect to the server using ldapsearch, I receive the following: $ ldapsearch -d7 -x -H ldaps://HOST:636 -D "BIND_DN" -W ldap_url_parse_ext(ldaps://HOST:636) ldap_create ldap_url_parse_ext(ldaps://HOST:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP HOST:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying HOST_IP:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS: could not add the certificate (null) - error -8018:Unknown PKCS #11 error.. TLS: /etc/openldap/cacerts/addtrust-ca.crt is not a valid CA certificate file - error -8018:Unknown PKCS #11 error.. TLS: could perform TLS system initialization. TLS: error: could not initialize moznss security context - error -8018:Unknown PKCS #11 error. TLS: can't create ssl handle. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) TLS: could not shutdown NSS - error -8053:NSS could not shutdown. Objects are still in use.. Is there a way, either through the ldap.conf, an environment variable, or through the API, to ignore the TLS portion of the handshake? Am I mistaken and something else is wrong here? Regards, Jon

11 years, 2 months

5
12
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical March 2012