Re: OpenLdap 2.4.17 and openssl 0.9.8l and datagram-based TLS
Robert Hanson wrote: Our customer is requiring us to use openssl 0.9.8l They have determined that there is a problem with datagram based TLS; as long as we’re not using datagram-based TLS for communication to slapd, we can go ahead and approve this. Please read this post http://www.openldap.org/lists/openldap-software/200911/msg00102.html and explain to your customer that OpenSSL 0.9.8l is broken and using it will result in hung connections. Nobody should be using it. 0.9.8m will probably be released soon due to the issues in 0.9.8l. How do I find out if I’m using datagram-based TLS? Is it something in the slapd.conf file or is it something in the build of openldap? Or is it just not an issue? It is not an issue. LDAP is a connection-oriented protocol, not datagram-based. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Same entry twice in ldapsearch output
Peter Mogensen wrote: Hi, It seems weird results are popping up faster than I can assemble test-setups to reproduce. ?!?! .. I'm lost. From all I know this should not happen on a healthy setup - unless there's something badly wrong with the procedure I've described above. It's slapd 2.4.19 with BDB4.8 Please test CVS RE24. 2.4.20 is being prepped for release and probably all of these issues have already been addressed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Binding with an e-mail address
Willie Gillespie wrote: Howard Chu wrote: No. LDAP Simple Bind requires DNs. Use SASL Bind if you want to use other forms of user names. Good to know. What is olcAuthIDRewrite used for then? Probably nothing. It hasn't ever been documented, you're probably the first person to ask about it in 8 years. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Two contextCSNs
-log
olcDbConfig: set_flags DB_LOG_AUTOREMOVE
olcDbConfig: set_lk_max_objects 5000
olcDbConfig: set_lk_max_locks 5000
olcDbConfig: set_lk_max_lockers 5000
olcDbCheckpoint: 1024 10
olcDbCachefree: 16
olcDbCachesize: 10
olcDbIDLcacheSize: 30
olcDbLinearIndex: FALSE
olcDbIndex: objectClass eq
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq
olcDbIndex: cn eq,sub
olcDbIndex: uid eq
olcDbIndex: ou eq
olcDbIndex: o eq
olcDbIndex: givenName eq,sub
olcDbIndex: sn eq,sub
olcDbIndex: mail eq,sub
olcDbIndex: member eq
olcDbIndex: reader eq
olcDbIndex: writer eq
olcDbIndex: admin eq
olcAccess:
to dn.base=cn=data,dc=example,dc=com attrs=userPassword
by * auth
olcAccess:
to dn.base=cn=data,dc=example,dc=com
by dn.base=cn=data,dc=example,dc=com search
olcAccess:
to dn.children=cn=data,dc=example,dc=com
by dn.base=cn=data,dc=example,dc=com write
olcSyncRepl: rid=3
provider=ldaps://server1.example.com:636/
searchbase=cn=data,dc=example,dc=com
type=refreshAndPersist
retry=60 +
scope=sub
schemachecking=on
bindmethod=sasl
binddn=cn=config
saslmech=EXTERNAL
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite=NULL-SHA
olcSyncRepl: rid=4
provider=ldaps://server2.example.com:636/
searchbase=cn=data,dc=example,dc=com
type=refreshAndPersist
retry=60 +
scope=sub
schemachecking=on
bindmethod=sasl
binddn=cn=config
saslmech=EXTERNAL
tls_cert=/etc/ldap/ssl/config.crt
tls_key=/etc/ldap/ssl/config.nopass.key
tls_cacert=/etc/ldap/ssl/ca.crt
tls_cipher_suite=NULL-SHA
olcMirrorMode: TRUE
olcLimits: dn.base=cn=config
size.soft=unlimited
size.hard=unlimited
time.soft=unlimited
time.hard=unlimited
dn: olcOverlay=syncprov,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
olcSpCheckpoint: 100 600
olcSpSessionlog: 100
olcSpReloadHint: TRUE
dn: olcOverlay=refint,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcRefintConfig
olcOverlay: refint
olcRefintAttribute: member
===
* All of the above gets properly replicated to server2.
* Then I take an LDIF from slapcat on slapd 2.3.30 and run:
$ cat dump.ldif | grep -v -E '^(entryCSN:|contextCSN:)' load_noCSN.ldif
The data (dump.ldif) looks like this (the root object):
===
dn: cn=data,dc=example,dc=com
objectClass: top
objectClass: NamedObject
objectClass: dcObject
objectClass: simpleSecurityObject
cn: data
userPassword:: BASE64
structuralObjectClass: NamedObject
entryUUID: ab7d5590-3e90-102c-8c03-91e70ecd3b46
creatorsName: cn=data,dc=example,dc=com
modifiersName: cn=data,dc=example,dc=com
createTimestamp: 20071214130312Z
modifyTimestamp: 20071214130312Z
entryCSN: 20071214130312Z#00#00#00
contextCSN: 20091118105948Z#01#00#00
=
* Then I STOP slapd on both servers.
* Then I load the output on server1:
$ slapadd -S 1 -q -w -l ~/load_noCSN.ldif
* Then I immediately slapcat this and move it to server2:
$ slapcat ~/toserver2.ldif
* And load it on server2:
$ slapadd -q -l ~/toserver2.ldif
* I start server1, but BEFORE I start server2 I make ONE SINGLE CHANGE:
=
dn: cn=data,dc=example,dc=com
changetype: modify
replace: userPassword
userPassword: NEWBASE64
=
* THEN I start server2 and monitor it's data.
What I find is that the contextCSN from server1 gets replicated, but the
change doesn't.
Also I see a contextCSN on server2 with SID 002 without I've done any
operations on server2.
No idea what that is. Your debug logs should tell what it was doing.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Password policy : Check_password module for debian
Hi, I would like to know how to use the check_password module that comes with the ppolicy overlay. A rpm package exists but i didn't find a debian one. I could compile it but i don't understand how to use the different options. Is there somebody that figured out how to use it on debian ? Do you know a good howto for debian ? The OpenLDAP Project doesn't provide any check_password module. You will have to ask whoever wrote the module you're talking about. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Syncrepl and rootdn
Dieter Kluenter wrote: Jaap Winiusjwin...@umrk.nl writes: Hi all, This question has to do with syncrepl and the use of the rootdn option in slapd.conf. My understanding is that on a provider server (where writes are possible), it is not necessary to use the rootdn option in slapd.conf. Instead it is enough to have an account that only exists in the directory, with ACLs that give it the same unrestricted access. This works fine for me. Any database requires a rootdn but not a rootpw. If no rootdn is defined in slapd.conf it defaults to cn=manager,$suffix, AFAIK. No, and no. The only database that has a rootdn by default is back-config. Your question should be what is the function of rootdn? On syncrepl consumers a rootdn in the local slapd.conf is apparently required (according to the man page for slapd.conf). Why is this, and Because the consumer needs to be able to store anything it receives, regardless of ACLs. does it make a difference what the name of the account is? No. For example, should it be the same as the binddn for syncrepl? No. For that matter, should rootpw also be set, No, that's not required. and should it then be the same as the credentials value used for syncrepl? No. The binddn within syncrepl has to have read access to the provider database and this should not be rootdn of the provider, rootdn of the consumer manages the consumer database only. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Developer's cookbook for adding LDAP support
Murray S. Kucherawy wrote: Are there any good documentation sites or books out there for adding LDAP support to a program? The ldap(3) man page is pretty sparse. I’ve been told that basically studying the OpenLDAP source itself is the best way to figure it out, but I’m hoping there’s something better. I have only very rudimentary knowledge of LDAP in general. Almost all of my exposure to OpenLDAP was through a helper library that did a lot of work for me, but that was at a previous job. This is for an open source project. The application to be updated already has support to get key-value pairs from SQL/ODBC and Sleepycat DB sources, and I have a request to include support for LDAP. Essentially in the application I am given an email recipient and I need to get from the database a piece of detail I need to append to that outgoing mail. There’s no standard schema for this (yet; it’s been suggested we create one through the IETF), so I will need to allow administrators to specify which attributes to request. Any helpful pointers would be appreciated. I recommend this: http://www.symas.com/blog/?p=38 Read the code in Ekiga, it's fairly compact and straightforward. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Chain overlay not available in Debian lenny?
Jaap Winius wrote: Hi all, Can anyone confirm that the chain overlay is not available in the version of OpenLDAP (2.4.11-1) that comes with Debian lenny? Although the man page for it still exists, loading it as a module result in an error (lt_dlopenext failed: (chain) chain.so: cannot open shared object file: No such file or directory), as does activating it (overlay chain not found) as well as attempts to use any of the chain- options in slapd.conf. Also, there's a Debian bug report (#502769, 19 Oct. 2008) with the subject when adding overlay chain to the slapd.conf slapd crashes with overlay chain not found. No mention is made of a solution, but could it be that the chain overlay was simply removed from the slapd package as result? The chain overlay is not a separate module, it's built into back-ldap. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Some openldap 2.4 questions
Radosław Antoniuk wrote: Hi, Three quick issues about slapd 2.4. 1. I'm setting up a syncrepl replication. In the process of testing, I had added three syncprov overlays instead of one, and I ended up with: The thing is, that I cannot delete any of them because cn=config does not support delete operation. Is this ok to leave it as is? or any workaround to get rid of the unwanted ones? Since it's just a test installation, your best action is to delete it all and start over with the correct LDIF. 2. About N-Way replication... What's the best authentication to use? Because (1) RootDN is the admin, and (2) in simple authentication I would store cleartext password in the syncrepl configuration, I'm assuming that (3) the best here would be to use some SASL mech? What do any of these 3 points have to do with each other, let alone with N-way replication? 3. Assuming a running normal replication(master-slave) with refreshAndPersist, is there any method of checking of the status of the replication? like show slave status in MySQL. I have tested it with cutting the transmission by iptables, and ok, it caught up after reconnection, but the master did not complain at all when the connection was not there... If you had read the docs http://www.openldap.org/doc/admin24/replication.html you wouldn't need to ask such questions. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Some openldap 2.4 questions
Radosław Antoniuk wrote: *Clearly* the provider SHOULD provide information, if it has pushed all the updates to the slaves. Ok, your excuse is that this is due to the fact, that the provider does not keep track of slaves. Ergo? The slaves are wrongly implemented. And *they* should provide the information if they have the connection and are up2date or not. This is of course totally implementation-dependent (in this case, I'd even risk the statement that it is quite wrongly implemented), when we have *no idea* if the slave copy is up2date or not. Obviously the consumer knows what its replication status is, but you can only determine whether a consumer is up to date or not when you have simultaneous access to both the consumer and the provider, to compare their status. If you sever the network connection, nothing can be inferred on either side about the other. Since you haven't bothered to read the design of syncrepl or the motivation behind it, you're in no position to judge the correctness of it. Answers like those, make me think that open-source is a waste of time comparing to paid solutions (even though I am a strong evangelist of Debian and other open source solutions, which I think the writer does not care about). The defining characteristic of open source is that the code is openly shared amongst developers and users. There is nothing implied about costs of operating it. If you believe there's a distinction between paid solutions and open source you're quite mistaken, the two are completely orthogonal. If you have a commercial enterprise, and you have even half a brain, you pay for support for your solutions, whether they are open or closed source. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Auth access for search-based mappings?
Jaap Winius wrote: Hi all, My OpenLDAP 2.4 test system uses Kerberos, SASL and GSSAPI. I've got person objects located in two different org. units and want to search both of them for a potential match, so I included these two statements in slapd.conf: authz-regexp uid=([^,]*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=eng,dc=example,dc=com??one?((uid=$1)(objectClass=person)) authz-regexp uid=([^,].*),cn=example.com,cn=gssapi,cn=auth ldap:///ou=bio,dc=example,dc=com??one?((uid=$1)(objectClass=person)) Unfortunately, it's not working as I hoped. If I have two test users, uid=john in ou=eng and uid=pete ou=bio, then after first authenticating them with the Kerberos kinit command, in this situation a subsequent ldapwhoami command for each will give: dn:uid=john,ou=eng,dc=example,dc=com dn:uid=pete,cn=example.com,cn=gssapi,cn=auth The second result is, of course, completely useless. However, if I change the order of two authz-regexp statements I get: dn:uid=john,cn=example.com,cn=gssapi,cn=auth dn:uid=pete,ou=bio,dc=example,dc=com Now the first result is useless. In other words, both authz-regexp statements work, but the second statement is being ignored. Why? How can I get slapd to also process the second authz-regexp statement? You can't. As the slapd.conf(5) manpage states, the matching process stops at the first rule that matches the incoming SASL name. If you want to use multiple authz-regexp statements, they must each have unique match portions because any duplicates will be ignored. For your case, you need to come up with a single search specification that will handle both branches of your search. One possible solution would be to use entryDN in the filter: ldap:///dc=example,dc=com??sub? ((|(entryDN:dnSubtree:=ou=eng,dc=example,dc=com) (entryDN:dnSubtree:ou=bio,dc=example,dc=com)) (uid=$1)(objectclass=person)) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: cn=config config problem
Alex Samad wrote: Hi I have setup a multimaster setup and some slave nodes, using cn=config. I am looking at trying to create a user in the cn=config space The config database does not support user entries, it only handles config entries. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Server-Side Sort Overlay ordering problems
Adam Tauno Williams wrote: On Thu, 2010-02-18 at 08:29 -0500, Adam Tauno Williams wrote: On Fri, 2010-01-15 at 11:27 -0200, Diego Lima wrote: I have enabled the server-side sorting overlay and I received the following error on a search: sssvlv: no ordering rule specified and no default ordering rule for attribute uid = get_ctrls: n=1 rc=18 err=serverSort control: No ordering rule send_ldap_result: conn=1000 op=7 p=3 send_ldap_response: msgid=8 tag=101 err=18 ber_flush2: 50 bytes to sd 13 Where should I specify the ordering rule for the uid attribute? The core schema? I believe I have this issue as well. Since upgrading to OL 2.4.20 our OpenFire XMPP server has been logging an unending stream of - 2010.02.15 11:02:26 [org.jivesoftware.openfire.ldap.LdapManager.retrieveList(LdapManager.java:1709)] javax.naming.directory.InvalidSearchFilterException: [LDAP: error code 18 - serverSort control: No ordering rule]; remaining name '' at com.sun.jndi.ldap.LdapCtx.mapErrorCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.processReturnCode(Unknown Source) at com.sun.jndi.ldap.LdapCtx.searchAux(Unknown Source) at com.sun.jndi.ldap.LdapCtx.c_search(Unknown Source) at com.sun.jndi.toolkit.ctx.ComponentDirContext.p_search(Unknown Source) No changes were made to the OpenFire configuration, so the issue must be do to a change in OL schema. Browsing our DSA's schema and cn and uid have no ordering rule. Setting the OpenFire server property ldap.clientSideSorting to true seems to have cleared up this issue. Without that property OpenFire was requesting the control 1.2.840.113556.1.4.473 on the uid attribute. Not sure what you're pointing out here. OpenLDAP doesn't advertise server-side sorting by default, you have to explicitly configure the overlay to get it. So there's no way that just upgrading to 2.4.20 would have suddenly caused this problem to start. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Nssov Problem Since 2.4.19
Chris Breneman wrote: Hi, For the last few days, I've been trying to get nssov to work. I've mainly been working with OpenLDAP 2.4.21, but this issue is present in all releases since and including 2.4.19. It works fine in 2.4.18. Everything compiles fine as expected, and the module loads (it seems), but when I try to add configuration for the module with ldapadd, I get this error: ldap_add: Other (e.g., implementation specific) error (80) additional info:olcOverlay handler exited with 1 Using the same build instructions, configuration, and everything, 2.4.18 works without this error. Some more details are below. Some built-in schema elements were moved out into a config file in 2.4.19. You probably need to add the ldapns.schema before configuring the overlay. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Nssov Authorization without Authentication
Chris Breneman wrote:
Is there a way to use nssov PAM LDAP for authorization (the PAM
account), without using it for authentication?
No.
I suspect this is because I'm not using nssov for the PAM
authentication. At the beginning of pam_authz() in nssov, I saw:
/* We don't do authorization if they weren't authenticated by us */
if (BER_BVISEMPTY(dn)) {
rc = NSLCD_PAM_USER_UNKNOWN;
goto finish;
}
Which leads me to believe that this is what is causing the problem.
It's not a problem - it's working as designed.
Indeed, when I change NSLCD_PAM_USER_UNKNOWN to NSLCD_PAM_SUCCESS there,
logins succeed (but authorization is not performed). If I just comment
out that block, logins still don't work, but I get the service not
permitted message.
Is there some way to make authorization work without first performing
authentication through nssov?
No. The authorization checks can only be performed if we know the LDAP DN of
the user. We only get that DN during authentication.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: DNS discovery for OpenLDAP?
Russ Allbery wrote: Jaap Winiusjwin...@umrk.nl writes: In the course of my research into a solution involving Kerberos, OpenLDAP and OpenAFS (a.k.a. the Magic Trio), I've discovered that both Kerberos and OpenAFS support methods of DNS discovery, but that OpenLDAP apparently does not. Is this correct? OpenLDAP's command-line tools support service discovery using DNS SRV records. See, for instance, the ldapsearch man page: -H ldapuri Specify URI(s) referring to the ldap server(s); a list of URI, separated by whitespace or commas is expected; only the protocol/host/port fields are allowed. As an exception, if no host/port is specified, but a DN is, the DN is used to look up the corresponding host(s) using the DNS SRV records, according to RFC 2782. I'm not sure if this is also available directly in the library or if the client has to implement it. This feature is implemented in the OpenLDAP client code, not in libldap. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: attribute 'pwdPolicySubentry' cannot have multiple values
Tyler Gates wrote: I'm pretty sure pwdPolicySubEntry requires the pwdPolicy objectClass in the target dn No. The pwdPolicy class is for the entry that contains the policy attributes, not the entry being controlled by the policy. although that wouldn't explain the error message... The error message is quite clear - the pwdPolicySubentry attribute is single-valued, you can't set multiple values for it. Are you sure the attribute doesn't already exist? It is a system attribute so depending on the browser you are using at may not appear. That's most likely what's going on here. On Mar 19, 2010, at 6:59 PM, Chris Jacobschris.jac...@apollogrp.edu wrote: Hello, I've got my ldap infrastructure (mirrormode masters, 2 slaves per datacenter) working fantastic (I can clear a db on a remote slave and in less than 30 seconds after startup, it'll reacquire the entire db!). I'm now having an issue with one of the very last things: getting a password policy into effect. When I attempt to add the 'pwdPolicySubentry' attribute to a user account, I get the error: Mar 19 22:51:24 ldapmaster1 slapd[8731]: Entry (uid=chrisjtest,ou=people,dc=unix,dc=aptimus,dc=net), attribute 'pwdPolicySubentry' cannot have multiple values Mar 19 22:51:24 ldapmaster1 slapd[8731]: entry failed schema check: attribute 'pwdPolicySubentry' cannot have multiple values I get that error in the logs whether I try to add it by hand via Apache Directory Studio, or an ldif import/modify: dn: uid=chrisjtest,ou=people,dc=unix,dc=aptimus,dc=net changetype: modify add: pwdPolicySubentry pwdPolicySubentry: cn=default,ou=policies,dc=unix,dc=aptimus,dc=net Here are the related slapd.conf overlay directives: overlay ppolicy ppolicy_hash_cleartext ppolicy_use_lockout (Notice there's no ppolicy_default set - I'm still testing this feature out before I roll it out.) And for completeness, here's the entry that I'm attempting to add this attribute to: dn: uid=chrisjtest,ou=people,dc=unix,dc=aptimus,dc=net objectClass: top objectClass: inetOrgPerson objectClass: posixAccount objectClass: shadowAccount cn: ChrisJ Test gidNumber: 200 homeDirectory: /home/chrisjtest sn: chrisjtest uid: chrisjtest uidNumber: 583 description: ChrisJ Test gecos: ChrisJ Test loginShell: /bin/bash shadowLastChange: 14657 userPassword::snipped And here's the password policy ldif: dn: ou=policies,dc=unix,dc=aptimus,dc=net objectClass: organizationalUnit objectClass: top ou: policies dn: cn=default,ou=policies,dc=unix,dc=aptimus,dc=net objectClass: top objectClass: device objectClass: pwdPolicy cn: default pwdAttribute: userPassword pwdAllowUserChange: TRUE pwdExpireWarning: 172800 pwdFailureCountInterval: 0 pwdGraceAuthNLimit: 0 pwdInHistory: 10 pwdLockout: TRUE pwdLockoutDuration: 1200 pwdMaxAge: 15897600 pwdMaxFailure: 3 pwdMinLength: 8 pwdMustChange: FALSE pwdSafeModify: TRUE When I built openldap, I enabled all overlays (I know, not the most efficient), and when I attempt to add moduleload ppolicy.la or ppolicy.so I get in the logs: line 18 (moduleload ppolicy.la) module_load: (ppolicy.la) already present (static) Which I'm pretty sure means it's already loaded... Any idea as to what I'm doing wrong? Thanks, - chris Chris Jacobs, Jr. Linux Administrator, Information Technology Operations Apollo Group | Apollo Marketing | Aptimus, Inc. 2001 6th Ave | Ste 3200 | Seattle, WA 98121 phone: 206.441-9100 x1245 | cell: 206.601.3256 | Fax: 208.441.9661 email: chris.jac...@apollogrp.edu This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: tls private key
Chris Jacobs wrote: There's one sure fire way to find out... Start it up with a syncrepl, then move the private key, and see if it syncs fine both ways. Wait a day or so, and make a change and see if that synced. If I had to put a dollar on it, if guess that it doesn't need the key after startup. I could be horribly wrong though - I'm not a dev, just a user of the software. It probably depends on which crypto library you built with. I'm pretty sure OpenSSL and GnuTLS cache the PEM credentials in memory. Not sure what MozNSS does. And of course, if you're paranoid, you can build these libraries to use smart tokens and leave the credentials there instead. :) - chris Chris Jacobs, Jr. Unix System Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: openldap-technical-bounces+chris.jacobs=apollogrp@openldap.orgopenldap-technical-bounces+chris.jacobs=apollogrp@openldap.org To: openldap-technical@openldap.orgopenldap-technical@openldap.org Sent: Thu Mar 25 18:44:47 2010 Subject: Re: tls private key HI On Fri, Mar 26, 2010 at 12:09 PM, Tyler Gatestgate...@gmail.com wrote: Alex, encrypting the private key really isn't necessary and I highly doubt it would work for your application nor be worth the hassel. Securing via file permisssions as mentioned previously is really the best way to tackle this. Think of 'other layers of protection' being firewalls, intrusion detection, restricted logins, chroot jails, etc., etc... yep go those, firewalls, permissions etc. I am not sure why every one is against me trying to use another layer of protection, just because I permission it as root.root 440, doesn't mean its safe. I could make it safer, but unecrypting the private key, starting slapd and removing the unecrypted file. Or thing of it another way, my private key could be on a usb key, that i insert into the machine on start up and remove once slapd has started. I have seen secure machine compromised before, somebody installed cvs forgot to change the cvs userid password, root hack and a remote user had access to the system. Some times people do silly things on my laptop - I encrypt the fs and the swap space and my gpg key have userid/passwords and my certs have userid password protection, like to do the same for my ldap setup as well :) I understand the reasons for encrypting and signing packets or information, just asking if slapd needs access to the private key after it has read the file on startup. Encryption really works best for UDP like transportation like email where you cannot guarantee the recipient is the only person able to 'see' the document ;) [snip] This message is private and confidential. If you have received it in error, please notify the sender and remove it from your system. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Re-engaging the Samba4 LDAP backend
Andrew Bartlett wrote: I'm trying to pick up the ball again on the OpenLDAP and Fedora DS backends, and hopefully to bring them back up to speed as a working and respectable solution. - A way to invoke slpad -Ttest -fconfig file -Fconfig dir without issuing errors because of the missing databases I already answered this quite a while back. Just add -n 0 to the invocation. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: ldap_ssl_client_init equivalent?
phi...@free.fr wrote: Hi, is there a ldap_ssl_client_init function in the openldap C API? I couldn't find any in the openldap header files. No, nor is one needed. A single ldap_initialize() API does everything needed for all LDAP session types. Requiring a separate API for each connection type would be stupid, and require pointless API revving when new types are added. What is the equivalent of the following ldapsearch query in C using the API, on Linux? If you want to know how ldapsearch does a query in C, just read the ldapsearch source code. ldapsearch -x -H 'ldaps://activedirectory.abc.com/636' -b 'dc=abc,dc=com' -D 'testdn' -W '((objectclass=user)(!(objectclass=computer))(samaccountname=myname))' samaccountname -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
New LDAP Appliances
No, not the VMware kind... http://www.symas.com/blog/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Partial replication
Andrew Findlay wrote: On Wed, Mar 31, 2010 at 08:43:19AM +0200, Zdenek Styblik wrote: How about to refuse rights to the syncrepl user? Actually, you could apply this to the whole tree. Just allow read to DNs you want to replicate. So, let's say you use cn=mirrorA,dc=domain,dc=tld for replication, then allow this cn=mirrorA to read only o=support,dc=example,dc=com and o=location_A,dc=example,dc=com, but nowhere else. I have used that technique for a fairly complex design with a central office and many small satellites. It works OK *provided* you never change the list of entries that can be seen by the replicas. The syncrepl system has no way to evaluate the effect of an ACL change (and probably no way to know that one has happenned). In this case it may be better to set up multiple replication agreements to cover the multiple subtrees required at the slave server. That would also make it possible to chain or refer queries for the rest of the DIT back to the master. Multiple agreements with the same provider won't work, since there will only be one contextCSN sent from the master. After the first consumer runs, the second one will assume it is up to date. The correct solution here is to use a extended filter with dnSubtreeMatch on each desired branch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Problem with SSL/TLS
Chris Jacobs wrote: /etc/ldap.conf is used by nss tools and the ilk. /etc/openldap/ldap.conf would be used by openldap tools - like ldapsearch. Actually it's used by libldap, which means everything that uses libldap (including nss_ldap). But of course the converse is not true, /etc/ldap.conf only affects nss_ldap and pam_ldap, not anything else. I have the same setting there for tls_checkpeer - but in the latter ldap.conf (under openldap). tls_checkpeer is not a valid OpenLDAP ldap.conf keyword. FWIW: there's apparently no real different format for the two files; while one would only be setup on ldap servers, mine are identical and things work with a If they are identical and things work, it's by sheer luck. Read the ldap.conf(5) manpage. Relying on anything not documented there would be a mistake. To the original poster: use the ldapsearch debug flag. OpenSSL s_client is not a reliable indicator of anything. mirror master, both setup behind a VIP (fail over, not load balanced) and a plethora of slaves in different subdomains. - chris PS: I'd forgotten to 'reply-to-all' earlier. :) Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jac...@apollogrp.edu -- *From*: Lynn York *To*: Chris Jacobs *Sent*: Mon Apr 12 10:29:19 2010 *Subject*: RE: Problem with SSL/TLS Here is my /etc/ldap.conf: #host 127.0.0.1 base cn=users,dc=testing,dc=com uri ldap://localhost:636 binddn cn=manager,dc=testing,dc=com bindpw password scope sub timelimit 120 bind_policy soft bind_timelimit 120 idle_timelimit 3600 ssl on tls_cacert /etc/openldap/cacerts/servercrt.pem tls_cacertdir /etc/openldap/cacerts tls_checkpeer no nss_base_group cn=groups,dc=testing,dc=com?sub pam_password md5 I have tried it with and without “tls_checkpeer”…. I am sort of at a loss as to what it can be. I also tested it using openssl client.. and here is the output: *From*: openldap-technical-bounces+chris.jacobs=apollogrp.edu http://apollogrp.edu@OpenLDAP.org *To*: openldap-technical@openldap.org mailto:openldap-technical@openldap.org *Sent*: Mon Apr 12 08:13:39 2010 *Subject*: Problem with SSL/TLS I have created a cert. on the server and openldap starts without any issues, however when I attempt to connect via ldaps I keep getting the following error: ?? ?? ldapsearch -x -H ldaps://localhost:636 -D cn=Manager,dc=testing,dc=com -W -b dc=testing,dc=com (objectClass=top) Enter LDAP Password: ldap_bind: Can't contact LDAP server (-1) ?? additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed ?? I can???t quite pin point what the problem might be.?? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP Data Directory issue
rahul.mancha...@bt.com wrote: Thanks for the reply. This I did as a part of platform AIS testing which includes that if the mount where the data directory is placed went offline then how will LDAP respond. Also where the data will get cached as I believe it should get cached in the data directory only? Though the reads were happening in this case but I checked inserting records as well and it worked. As I believe inserts should not happen at all in this case if data directory does not exists at all. Please suggest. Learn how Unix works. Deleting files doesn't actually remove them if a process still has a file descriptor open on those files. If you wanted to test the behavior of a mount point going offline then you should have done exactly that - unmount the mount point. You would have to use a force option if the mount point still has files open on it, and if you successfully dismount, slapd will certainly start failing operations with Internal Error soon after. Regards Rahul Manchanda -- Andes , Selfcare Platform Build Team tel: (+91) (20) 66018100 extn: 6178; e-mail: rahul.mancha...@bt.com Address: Tech Mahindra, Sharada Center, Erandwana Pune-4 -Original Message- From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] Sent: Tuesday, April 13, 2010 9:00 PM To: Manchanda,RK,Rahul,DKE C; openldap-technical@openldap.org Subject: Re: OpenLDAP Data Directory issue --On Tuesday, April 13, 2010 4:39 PM +0100 rahul.mancha...@bt.com wrote: Hello, For a running LDAP if I delete the data directory still the LDAP is responding to reads and writes without giving any error. All logins in related to application are working fine. Is this picking the data from cache or actual data itself is getting stored somewhere. Can someone please provide his/her technical expertise on this behavior? It's unsupported and you should never delete it while LDAP is running. It likely is still cached in memory. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc Zimbra :: the leader in open source messaging and collaboration -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: _ldap.so: undefined symbol: gnutls_alert_send
Jean-Sébastien Mansart wrote: Hi. I've got this error with a Zope/Plone site : Nothing in this trace is a part of OpenLDAP software. Nothing in OpenLDAP calls gnutls_alert_send(). Sounds like you need to contact the actual authors of the code you're working with. Traceback (most recent call last): File /zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py, line 56, in ? run() File /zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/run.py, line 21, in run starter.prepare() File /home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py, line 102, in prepare self.startZope() File /home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/Startup/__init__.py, line 278, in startZope Zope2.startup() File /home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/__init__.py, line 47, in startup _startup() File /home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/Zope2/App/startup.py, line 45, in startup OFS.Application.import_products() File /home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py, line 686, in import_products import_product(product_dir, product_name, raise_exc=debug_mode) File /home/zope/z_sgec/Zope-2.10.11-final-py2.4/lib/python/OFS/Application.py, line 709, in import_product product=__import__(pname, global_dict, global_dict, silly) File /home/zope/z_sgec/buildout-cache/eggs/Products.LDAPMultiPlugins-1.9-py2.4.egg/Products/LDAPMultiPlugins/__init__.py, line 22, in ? from Products.LDAPMultiPlugins.LDAPMultiPlugin import addLDAPMultiPluginForm File /home/zope/z_sgec/buildout-cache/eggs/Products.LDAPMultiPlugins-1.9-py2.4.egg/Products/LDAPMultiPlugins/LDAPMultiPlugin.py, line 29, in ? from Products.LDAPUserFolder import manage_addLDAPUserFolder File /home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/__init__.py, line 20, in ? from Products.LDAPUserFolder.LDAPUserFolder import LDAPUserFolder File /home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/LDAPUserFolder.py, line 47, in ? from Products.LDAPUserFolder.LDAPDelegate import filter_format File /home/zope/z_sgec/buildout-cache/eggs/Products.LDAPUserFolder-2.16-py2.4.egg/Products/LDAPUserFolder/LDAPDelegate.py, line 19, in ? import ldap File /home/zope/z_sgec/buildout-cache/eggs/python_ldap-2.3.11-py2.4-linux-i686.egg/ldap/__init__.py, line 22, in ? from _ldap import * ImportError: /home/zope/z_sgec/buildout-cache/eggs/python_ldap-2.3.11-py2.4-linux-i686.egg/_ldap.so: undefined symbol: gnutls_alert_send I have install gnutls1.3, recompiled openldap, python-ldap, and so on, but nothing works. Anyone could help me ? Thanks. -- *Jean-Sébastien Mansart *- Développeur Web Email : jean-sebastien.mans...@bayard-service.com mailto:jean-sebastien.mans...@bayard-service.com Tel : 04 79 26 28 29 *Bayard Service Edition * Savoie Technolac - House Boat BP308 - 73377 Le Bourget du Lac Cedex www.bayardserviceweb.com http://www.bayardserviceweb.com -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: bdb_index_read: failed
Arwin wrote: Hi all, We are running 1 master server and a couple of slaves, all openldap-2.4 on Ubuntu 8.04 lts, syncrepl and cn=config configuration. The last couple of days we are getting a few of the following errors in the slapd logs: Apr 29 11:03:41 ldapsrvr-1 slapd[6112]: bdb_idl_fetch_key: [b49d1940] Apr 29 11:03:41 ldapsrvr-1 slapd[6112]:= bdb_index_read: failed (-30990) Apr 29 11:03:41 ldapsrvr-1 slapd[6112]:= bdb_equality_candidates: id=0, first=0, last=0 Apr 29 11:03:41 ldapsrvr-1 slapd[6112]: = bdb_equality_candidates (objectClass) Tried solving it by re-adding the index and running slapindex but the errors still remain. Everything seems to work ok though, replication works, we can add/edit entries and user authentication of accounts in the dit work just fine. Can anybody tell me if this (bdb_index_read: failed (-30990)) is something that needs to be fixed and if so, how? No. It's normal, it just means it was looking for the index of a value that doesn't exist in your DB. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: bdb_index_read: failed
Chris Jacobs wrote: This was all assuming that this was an established service - and if you've simply taken over an admin role, this could have been going on for a while and the final 'culprit' may simply be missing indexes. There is no missing index. The index is working correctly, it was simply asked to find a value that does not exist. There's nothing abnormal about that, there's nothing to fix. This whole thread is much ado about nothing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: More on dynamic group searches
Ian Collins wrote:
Hello,
This is my first post here, so if I'm going over old ground, please let
me know (I have searched).
I have looked through the archives and reached the conclusion that there
isn't a convenient means of searching for groups based on a dynamic
entry. For example, if I have a dynlist entry containing
olcDlAttrSet: {0}groupOfURLs memberURL uniqueMember
uniqueMember is dynamically added to search results, but can't be part
of the search.
Is this conclusion correct?
Yes.
I am migrating a client over from Sun's directory manager (which does
allow searching on dynamic attributes) to OpenLDAP, so I have to support
all the client applications that currently authenticate against and use
LDAP. For example:
filter=((objectClass=posixGroup)(uniqueMember=cn=Admins,ou=groups,o=staff,dc=company))
attrs=gidNumber
Don't use dynamic groups then. Use autogroups.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to obtain a 'version number' of an attributes
Andrew Bartlett wrote: I've got a little challenge... there is an attribute in AD call msDS-KeyVersionNumber. In AD this operational attribute increments each time the unicodePwd attribute is updated. It is typically a small integer, being the number of times that the password has ever been changed. In Samba4, we maintain this by looking into our replication metadata (replPropertyMetaData), and returning a counter that is maintained there. I could maintain this manually from Samba's side (this is what we did in the past), but I wanted to first check if there was something already stored that I could convert. We don't keep a counter on the LDAP side. However, the Heimdal KDC maintains the keyVersionNumber, and it seems to me that you'd have that integrated here as well. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Summary of dynamic groups
Ian Collins wrote: Hello again, My earlier thread appears to have been hijacked, so I'm starting a new one for the summary of my investigations. My current understanding is as follows: There are three overlays that can use yes to manage groups dynamically: dynlist, autogroup and memberof. - dynlist works well for including members specified in a URL to the result of a search on a group. The dynamic members can not be included in a search filter. - autogroup works well for including members specified in a URL to the result of a search on a group. The dynamic members can be included in a search filter, but the only supported list attribute is 'member', which limits its use. That's false, you can configure it to use any attribute type. However, uniqueMember is a broken attribute type and should not be used by any LDAP software. - memberof works well for reverse group management, including group dn in the entries for group members. It only works with DN-values attributes, so it can't be used with clients that expect POSIX group members to be listed by 'memberUid' rather than 'member'. POSIX group / memberUid is deprecated, no new LDAP clients should be using it anyway. uniqueMember and memberUid have been discussed at length on these mailing lists before, so I won't elaborate again here. Search the archives for context. From the above, I don't see a way to use OpenLDAP in an existing environment where dynamic groups are searched for by members and don't list their members with the 'member' attribute. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Summary of dynamic groups
Ian Collins wrote: On 05/26/10 02:40 PM, Howard Chu wrote: Ian Collins wrote: Hello again, My earlier thread appears to have been hijacked, so I'm starting a new one for the summary of my investigations. My current understanding is as follows: There are three overlays that can use yes to manage groups dynamically: dynlist, autogroup and memberof. - dynlist works well for including members specified in a URL to the result of a search on a group. The dynamic members can not be included in a search filter. - autogroup works well for including members specified in a URL to the result of a search on a group. The dynamic members can be included in a search filter, but the only supported list attribute is 'member', which limits its use. That's false, you can configure it to use any attribute type. No according to the read me: The valuemember-ad is the name of the attributeDescription that specifies the member attribute. User modification of this attribute is disabled for consistency. I could only et it to work with 'member'. Even if I specified 'uniqueMember', 'member' was inserted. Then there's something else interfering in your config. There is nothing in the autogroup code that gives preference to the member attribute. It uses the attribute type you configure, and nothing else. Of course, the objectclass you use must also allow the attribute type you chose. The text you quote above merely states that whatever attribute you choose will no longer be user-modifiable; the member list will always contain only the dynamically-generated values. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: pam_ldap doesn't bind SIMPLE for anonymous auth?
Jo Rhett wrote: On Jun 9, 2010, at 12:37 PM, Russ Allbery wrote: I can tell you in general why a PAM module would do that. One of the much faster than the first. This information disclosure vulnerability could then be used to further target brute-force password attacks and I understand that. I believe that my complaint about the logging problem is valid. If you look at the log excepts below, it appears that in one scenario no BIND attempt occurred. Logging it for success but not for failure in the logs (see where it skips right to send-ldap_result without logging the BIND attempt) tends to lead someone down the wrong road when debugging the problem. You're overlooking the obvious fact, which we repeat on these lists far too many times, that syslog is lossy and cannot be relied on as a debugging aid. There's a reason slapd has an explicit -d debug flag, distinct from the syslog flags. Your log excerpt here clearly shows that it's sending a reply to an operation with id op=2, so obviously some other operations have already occurred on this connection. (Since operation counters always start from 0.) Either they're missing from your log or you just didn't snip the right portion of the log. Either way, the fact that there's no Bind request in this snippet doesn't mean that the Bind request didn't occur, or that slapd didn't attempt to send it to syslog. Jun 4 14:58:52 ldap-server slapd[5158]: = dn: [1] Jun 4 14:58:52 ldap-server slapd[5158]: = acl_get: [2] attr userPassword Jun 4 14:58:52 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: access to entry uid=jrhett,ou=Users,dc=equinix,dc=com, attr userPassword requested Jun 4 14:58:52 ldap-server slapd[5158]: = acl_mask: to value by , (=0) Jun 4 14:58:52 ldap-server slapd[5158]:= check a_dn_pat: anonymous Jun 4 14:58:52 ldap-server slapd[5158]:= acl_mask: [1] applying auth(=xd) (stop) Jun 4 14:58:52 ldap-server slapd[5158]:= acl_mask: [1] mask: auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: = access_allowed: auth access granted by auth(=xd) Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: conn=75 op=2 p=3 Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_result: err=49 matched= text= Jun 4 14:58:52 ldap-server slapd[5158]: send_ldap_response: msgid=3 tag=97 err=49 Jun 4 14:58:52 ldap-server slapd[5158]: conn=75 op=2 RESULT tag=97 err=49 text= Jun 4 15:02:54 ldap-server slapd[5158]: = acl_get: [2] attr userPassword Jun 4 15:02:54 ldap-server slapd[5158]: access_allowed: no res from state (userPassword) Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: access to entry uid=jrhett,ou=Users,dc=equinix,dc=com, attr userPassword requested Jun 4 15:02:54 ldap-server slapd[5158]: = acl_mask: to value by , (=0) Jun 4 15:02:54 ldap-server slapd[5158]:= check a_dn_pat: anonymous Jun 4 15:02:54 ldap-server slapd[5158]:= acl_mask: [1] applying auth(=xd) (stop) Jun 4 15:02:54 ldap-server slapd[5158]:= acl_mask: [1] mask: auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: = access_allowed: auth access granted by auth(=xd) Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 BIND dn=uid=jrhett,ou=Users,dc=equinix,dc=com mech=SIMPLE ssf=0 Jun 4 15:02:54 ldap-server slapd[5158]: do_bind: v3 bind: uid=jrhett,ou=Users,dc=equinix,dc=com to uid=jrhett,ou=Users,dc=equinix,dc=com Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: conn=83 op=0 p=3 Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_result: err=0 matched= text= Jun 4 15:02:54 ldap-server slapd[5158]: send_ldap_response: msgid=1 tag=97 err=0 Jun 4 15:02:54 ldap-server slapd[5158]: conn=83 op=0 RESULT tag=97 err=0 text= Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on 1 descriptor Jun 4 15:02:54 ldap-server slapd[5158]: daemon: activity on: -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Communicate from php/apache to openLDAP over LDAPS
Jérémy ESCOLANO wrote: I tried to put host=srvLDAP but it still doesn't work Actually the problem is configuring my APACHE server to make it considerate theses certificate. I know there is a ldap.conf in the openLDAP directory (on openLDAP server) where to have to put : TLS_CACERT ./ssl2/cacert.cer TLS_REQCERT demand but how can we specify it on apache server ? Ask on an Apache forum. Thanks 2010/6/10 Thierry Lacoste laco...@u-pec.fr mailto:laco...@u-pec.fr Seems to me that the $host variable is incorrect : should be $host=srvLDAP HTH, Thierry On 10 juin 10, at 10:57, Jérémy ESCOLANO wrote: Hi I'm writing from france cuz i'm having a big problem with apache and ldap. let me explain : I would like to make an Apache server communicate in php with en openLDAP server (both servers are under win srv 2003), using LDAPS protocol. In order to activate LDAPS on my openLDAP srv (srvLDAP), I created self signed certificates with openSSL. I got 3 files: cacert.pem srvLDAP.pem srvLDAP.key I configured my slapd.con file and ldap.conf fil (openLDAP side) like this: slapd.conf TLSCertificateFile ./ssl/srvLDAP.pem TLSCertificateKeyFile ./ssl/srvLDAP.key TLSCACertificateFile./ssl/cacert.pem ldap.conf BASE ma branche URI ldaps://srvLDAP/ TLS_CACERT ./ssl/cacert.pem TLS_REQCERT demand I launched my openLDAP service, and checked ldaps protocol was okay, using this command : C:\Program Files\OpenLDAPldapsearch -b o=exemple,dc=fr -s sub -x -w pass-D cn=admin,o=exemple,dc=fr -H ldaps://srvLDAP/ Now I would like, from the remote apache server, communicate with the openLDAP server using [b]LDAPS[/b] Protocol. Here is my simplified PHP code h2LDAP OPENLDAP LDAPS/h2 ?php $host=ldaps://srvldap; $port=636; $ds=ldap_connect($host,$port); ldap_set_option($ds,LDAP_OPT_PROTOCOL_VERSION,3); $r=ldap_bind($ds,cn=admin,o=exemple,dc=fr,pass ); $sr=ldap_search($ds,o=exemplec,dc=fr,(objectClass=maclasse )); $info=ldap_get_entries($ds,$sr); print $info[count]. enregistrements trouvés.; ? I get this errror: Unable to bind to server: Can't contact LDAP server I know i have to configure certificates in the Apache server configuration, I tried to to this according several internet ressources but didn't succeed. I also read this link [URL=http://forum.hardware.fr/hfr/OSAlternatifs/Logiciels-2/certificats-securisee-connexion-sujet_65365_1.htm]Here[/URL] which is a french link which speak about an ldap.con and ldaprc files to put in the apache server. I did it but nothing happened. Well, i'm lost in all this stuff, that is why i'm asking for help to configure my servers to use ldaps with php. Do you have information that could help me ? I thank you in advance -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Communicate from php/apache to openLDAP over LDAPS
Dieter Kluenter wrote: Jérémy ESCOLANOjeremyescol...@gmail.com writes: I see, so I need to configure the Apache server to make it able verify the ldap server certificate by using the certificate authority. That is what I don't know how to do it. If it can help, here is the error I get : SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate s3_srvr:2471 You have configured slapd to request a client certificate which the client does not provide, just set TLSVerifyClient never in slapd.conf and TLS_REQCERT try (or demand) in ldap.conf or any other client configuration file. Just don't specify TLS_REQCERT at all in ldap.conf. The default is demand and should not be changed. In all of this thread no one has asked or stated what version of OpenLDAP is being used... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Restricting client access using pam_groupdn with dynamic groups : Was[Re: restrict host login based on group]
decide to do it based on group membership, I can use pam_groupdn but then it does not allow multiple group entries there, plus it has to be managed on client side,which is even more undesirable by any administrator. I went through this article but I'm not sure if it will work if I have some members already associated with some groups. Like ldap1 ldap2 members of qagroup ldap3 ldap4 members of sysadmin, would this method allow me to limit access based on their group membership?? if yes...could you briefly explain with an example? Thank for your time in advance Shamika On Wed, Dec 9, 2009 at 9:04 AM, Adam Hough a...@gradientzero.com mailto:a...@gradientzero.com wrote: Here is is the write up that I read to figure out how to do setup to auto-restrict users to certain hosts. http://www.hurricanelabs.com/september2009_login_security_using_openldap_and_pam -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Tool to covert from LDIF cn=config to slapd.conf?
Francis Swasey wrote: On 6/9/10 3:32 PM, Quanah Gibson-Mount wrote: slapd.conf is deprecated and will likely be removed in OpenLDAP 2.5. Do all of the overlays support cn=config yet? Last I remember, there were still overlays that didn't work with cn=config. If your memory is correct, you're welcome to submit patches. I would rather that cn=config was working with everything for one entire release before slapd.conf is removed to give those of us that depend on those overlays a chance to migrate -- rather than a repeat of the forced conversion to syncrepl before it was completely baked (which I for one do not think has completely happened even now in 2.4.22). All of the core overlays support cn=config. You can always pull slurpd from CVS if you enjoy that sort of thing, no one put a gun to your head to force you in any direction. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to use BLOB while using Back-NDB
Priyesh Potdar wrote: Hi All, I am using back-ndb as a backend for my openldap. I want to know, what is configuration change in slapd.conf I need to make to instruct openldap to always use BLOB and not the VARCHAR. Use attrblob attribute. Apparently this is missing from the manpage. You should file an ITS so that we can get the manpage updated. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Best way to merge two local DITs vs empty search base suffix
Chris Jacobs wrote: Where is it documented how the conf file slapd.conf file is processed? I've read the documentation, more than once, and still don't know. I suspect this whole 'order thing' is pretty darn important (outside of access config). slapd.conf(5): suffix dn suffix Specify the DN suffix of queries that will be passed to this backend database. Multiple suffix lines can be given and at least one is required for each database definition. If the suffix of one database is inside that of another, the database with the inner suffix must come first in the configuration file. Seriously, please me at it. Thanks, - chris Chris Jacobs, Systems Administrator Apollo Group | Apollo Marketing | Aptimus 2001 6th Ave Ste 3200 | Seattle, WA 98121 phone: 206.441.9100 x1245 | mobile: 206.601.3256 | fax: 206.441.9661 email: chris.jac...@apollogrp.edu - Original Message - From: openldap-technical-bounces+chris.jacobs=apollogrp@openldap.orgopenldap-technical-bounces+chris.jacobs=apollogrp@openldap.org To: guy.baconni...@swisscom.comguy.baconni...@swisscom.com; openldap-technical@openldap.orgopenldap-technical@openldap.org Sent: Sun Jun 13 20:20:07 2010 Subject: Re: Best way to merge two local DITs vs empty search base suffix --On Sunday, June 13, 2010 12:17 PM +0200 guy.baconni...@swisscom.com wrote: Hello, We want to update our old OpenLDAP server from 2.1.x to 2.4.x but the current configuration do not use a regular suffix (o=foo,c=bar nor dc=foo,dc=bar) but use an empty suffix (). We want to move away from empty suffix as we cannot use cn=monitor or any additional suffixes as they can not bind when a suffix is in use in a hdb database : You can do this just fine. I do it in all my installs. You simply need to declare them in the right order. I.e., you must declare monitor, etc before the empty suffix. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: failed to start slapd can't create password - please help.
sam wrote:
Hi Gibson,
Thank you for your response.
How can I build Openldap with MD5 support?
Would the following make options work?
Quanah's post leapt to a premature conclusion. You should first check to see
if using quotes works {MD5} since curly brackets are special in most command
shells.
And of course, you should pay attention to the docs since the slappasswd(8)
manpage already warns you that quotes will probably be needed.
--enable-modules --enable-crypt
Thanks
Sam
Quanah Gibson-Mount wrote:
--On Sunday, June 20, 2010 11:20 AM +1000 sams...@ip6.com.au wrote:
Hi,
With the following setup:
hometest:openldap # uname -a
FreeBSD hometest.ip6.com.auhttp://hometest.ip6.com.au 8.1-RC1 FreeBSD
8.1-RC1 #0: Fri Jun 18
15:26:58 EST 2010
r...@hometest.ip6.com.au:/usr/
obj/usr/src/sys/mail.db.java.portal
i386
hometest:openldap # pkg_info | grep -i ldap
openldap-sasl-client-2.4.22 Open source LDAP client implementation
with SASL2 support
openldap-sasl-server-2.4.22 Open source LDAP server implementation
hometest:openldap # pkg_info | grep -i db
db46-4.6.21.4 The Berkeley DB package, revision 4.6
hometest:openldap # pkg_info | grep -i sasl
cyrus-sasl-2.1.23 RFC SASL (Simple Authentication and Security
Layer)
cyrus-sasl-saslauthd-2.1.23 SASL authentication server for cyrus-sasl2
openldap-sasl-client-2.4.22 Open source LDAP client implementation
with SASL2 support
openldap-sasl-server-2.4.22 Open source LDAP server implementation
I can't create password for ldap:
hometest:openldap # slappasswd -h {MD5} -s password
Password generation failed for scheme MD5: scheme not recognized
It wasn't built with MD5 support. If it is, it works:
[zim...@freelancer ~]$ /opt/zimbra/openldap/sbin/slappasswd -h {MD5}
-s blah
{MD5}bx7QAqtVlYWQFOvwlRUi2Q==
hometest:rc.d # ./slapd start
Starting slapd.
./slapd: WARNING: failed to start slapd
Run slapd -d -1 to see why it failed to start.
--Quanah
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Unigueness of RID; changing RID
Nick Urbanik wrote: Dear Folks, I am trying to improve my understanding of the RID before making many large deployments of syncrepl. My understanding is that the replica ID (RID) is unique within one level of [provider] -- [consumer], [consumer],... relationship. That is not what the documentation says. Where did you get this understanding? An RID is just a unique tag within a single slapd.conf or slapd.d. Its only purpose is to provide an unambiguous ID that can be referenced from the slapd -c option. That's all. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Can password-hash be database specific? also, storing and verifying cleartext passwords
masar...@aero.polimi.it wrote:
-Original Message-
Is the 'password-hash' configuration function a server-wide setting
only
or can it be set to different values for separate databases?
I'm trying to add MAC-auth RADIUS functionality to my LDAP server
(openldap-2.4.21) and I need to store the password for the MAC
addresses
in cleartext. I also use the LDAP server for user login which I don't
want to keep in cleartext. So, my thought was to have 'password-hash
{SSHA}' for the users database, and 'password-hash {CLEARTEXT}' for the
RADIUS database, but it appears that it's a global so I'm pretty sure
this won't work.
Yes, each database can have a different hashing mechanism set.
http://www.openldap.org/software/man.cgi?query=slapd-configapropos=0sektion=0manpath=OpenLDAP+2.4-Releaseformat=html
I'm afraid that man page is incorrect. As far as I know, that directive
is global, not database specific. That's what I get from the code (and
what I remembered). You can check yourself by adding the directive and
inspecting the content of cn=config.
We need at least to fix the manpage.
The manpage is correct. It clearly states This setting is only allowed in the
frontend entry.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Can password-hash be database specific? also, storing and verifying cleartext passwords
masar...@aero.polimi.it wrote: The manpage is correct. It clearly states This setting is only allowed in the frontend entry. Right; I was mistaken by the fact that olcPasswordHash is allowed by class olcGlobal. Yes, it's allowed in olcGlobal for backward compatibility with slapd.conf, which didn't enforce any distinction between global and frontend directives. But it's not evaluated there, since it's possible to specify a hash mechanism that is loaded from a module (and the moduleLoad parsing hasn't occurred yet when olcGlobal is read). -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: openldap mysqlcluster and FreeRadius Schema
Levent ILDENIZ wrote: Hi, i have a problem about openldap with mysqlcluster and with free radius schema i inserted freeradius schema statement in my slapd.conf when i create any user with radiusprofile, i see below failure messages * /ndb_oc_create: CREATE TABLE radiusprofile failed, Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8052. You have to change some columns to TEXT or BLOBs (1118) ndb_back_add: ndb_entry_put_data failed (80) Tuple did not exist(626)/* how can i fix this? If you have some attributes defined with fairly large maximum sizes, then you might consider defining them as blobs using attrblob attr. If all of the attributes are of average size, and you simply have too many of them to fit in a single table, then you should break them up into separate attrsets. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: nssov overlay socket and chrooted software
b...@bitrate.net wrote: hi- i'm using the nssov overlay, which is hard coded (i believe?) to present it's socket at /var/run/nslcd/socket. this presents a problem for software (in this particular case, postfix) that is chrooted and can't see the socket. can i configure the overlay to create multiple sockets (sort of along the same lines as rsyslog, for example)? No, currently there is no support for configuring the socket path, or multiple sockets. Patches to add this feature are welcome. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to best handle DN+String and DN+Binary in OL?
Andrew Bartlett wrote: I'm back on my occasional task of trying to get the OpenLDAP backend to Samba4 going again, and was hoping to simply test out the fine work done on the vernum module. (which I should have tested at the time it was developed). Anyway, Samba has moved on, and things have broken. Part of the changes relate to these additional DN types (found in AD), of: #define DSDB_SYNTAX_BINARY_DN 1.2.840.113556.1.4.903 http://msdn.microsoft.com/en-us/library/ms684429%28VS.85%29.aspx #define DSDB_SYNTAX_STRING_DN 1.2.840.113556.1.4.904 http://msdn.microsoft.com/en-us/library/ms684430%28VS.85%29.aspx #define DSDB_SYNTAX_OR_NAME 1.2.840.113556.1.4.1221 http://archives.free.net.ph/message/20091211.162430.74b43d9e.en.html These are quite odd in their behaivour, but in short they are both a string or binary blob and a DN, all in one. Only the DN portion is relevant for attribute matching rules. Currently, I map these to strings, but they are not strings - and need proper DN match rules, as I need to be able to use the 'deref' module on them (and to correctly handle the case sensitive/insensitive nature of DNs). What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values? Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted. (Additionally, even when just use deref with normal DNs, I'm not getting a the control response, but I need to get more info before I can pin the details down) Thanks, Andrew Bartlett -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to best handle DN+String and DN+Binary in OL?
Andrew Bartlett wrote: On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote: Andrew Bartlett wrote: What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values? Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted. Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits. Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead. If as you say, the blob portion is irrelevant for matching, then you would just store the normalized DN portion as the attribute's normalized values, and most things that work with DNs will Just Work. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to best handle DN+String and DN+Binary in OL?
Howard Chu wrote: Andrew Bartlett wrote: On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote: Andrew Bartlett wrote: What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values? Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted. Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits. Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead. The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to best handle DN+String and DN+Binary in OL?
Andrew Bartlett wrote: On Sun, 2010-07-11 at 18:25 -0700, Howard Chu wrote: Howard Chu wrote: Andrew Bartlett wrote: On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote: Andrew Bartlett wrote: What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values? Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted. Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits. Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead. The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute. So, how do I define a new syntax for this? Have a look at the contributed code in ITS#6247 for an example. http://www.openldap.org/its/index.cgi/Contrib?id=6247 -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to best handle DN+String and DN+Binary in OL?
masar...@aero.polimi.it wrote: Howard Chu wrote: Andrew Bartlett wrote: On Sun, 2010-07-11 at 14:16 -0700, Howard Chu wrote: Andrew Bartlett wrote: What is the best way to get OpenLDAP to understand it needs to match on and follow references to the DN part of these values? Good question. So far the only way to get DN semantics is by using distinguishedName syntax. In a few places we've also special-cased recognition of NameAndOptionalUID syntax, but that's not universal. I suppose, if you can shoehorn your extra blobs into the UID portion, you can use that syntax and we can figure out where else it needs to be accepted. Looking over the definition of NameAndOptionalUID, shoehorn would certainly be the correct expression... But yes, it looks to me like I just need to convert every binary or string element into a bitstring of it's bits. Yeah, bitstrings are a PITA. The better way might be to just define a new syntax and matching rules that stores exactly what you want. We can define a new syntax flag SLAP_SYNTAX_DN_LIKE or somesuch, and change all of those places that were hardcoded to look for DN syntax to use this flag instead. The other places that are interesting in this regard are in the ACL engine and anything that uses librewrite. Rewrites are trickier because the rewrite code needs to be able to isolate just the DN portion for rewriting, and preserve any other blob attached to an attribute. This would probably be the caller's business; for example, slapo-rwm and back-meta where DN-valued (or SLAP_SYNTAX_DN_LIKE-valued) attributes are rewritten. Probably, each syntax normalizer's duty would be to isolate the DN portion and feed it to dnNormalize(). Yes, but that's only part of it. We also need to back that into the Pretty'd value without losing the blob. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Attribute type is operational
Jonathan Clarke wrote: On Mon, 12 Jul 2010 08:10:56 +, Stuart Cherrington stuart_cherring...@hotmail.co.uk wrote: Hi, I'm running Openldap 2.4 on Rhel5. I've got the basics working, user accounts etc, but have tried adding some new schemas which I'm getting problems with. I followed a VERY helpful Blog at http://oracle-cookies.blogspot.com/2007/01/get-tnsnamesora-from-openldap.html which allowed me to install some Oracle OID schema's so we can move away from Oracle OID. This Blog is a little out of date and I have some attributetypes which I need to add-in to the schema. I've added the following 2 lines: attributetypes ( 2.16.840.1.113894.1.1.37 NAME 'orclGuid' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.15' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) attributetypes ( 2.16.840.1.113894.1.1.1000 NAME 'orclnormdn' EQUALITY distinguishedNameMatch SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) I took these from the current 10.2.0 OID installation so wasn't 100% sure they were correct but they are similar in construct the others found on the blog. When I restart ldap2.4 I get error: service ldap2.4 restart Checking config file /etc/openldap2.4/slapd.conf: [FAILED] /etc/openldap2.4/schema/oidbase.schema: line 27 attributetypes: 2.16.840.1.113894.1.1.37 is operational slaptest2.4: bad configuration file! This error message is complaining that the attributetype declared is an operational attribute (USAGE directoryOperation). Reading through the code, I see the following comment: operational attributes should be defined internally. I therefore presume that you cannot define operational attributes by way of schema files. Correct. Operational attributes are, by definition, used internally by a directory server. They have no meaning unless you provide code that implements them. These attributes won't be operational anyway in the sense that they will not be automatically managed by the OpenLDAP server, since it knows nothing about them. If you just need them for compatibility with OID, I suggest you change the declaration to make them non-operational. You'll probably want to remove the NO-USER-MODIFICATION flag too, if you want to be able to modify them with user accounts. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: need an overlay for rewriting attribute values
Thomas Wunder wrote: Hi, I need some kind of overlay which allows me to rewrite attribute values. I.e. if there's an object cn=a,ou=src,dc=my,dc=com which has attributes like memberUid=uid=usrA,ou=rest,ou=of,dc=the,dc=dn and memberUid=uid=usrB,ou=rest,ou=of,dc=the,dc=dn I want that overlay to suffixmassage (or whatever) it to an object like cn=b,ou=dst,dc=my,dc=com where for example memberUid=usrA memberUid=usrB but the rest (i.e. other Attributes like 'gidNumber', 'userPassword', 'description',...) of the object should be identical to the 'source'-object. The whole thing is needed because slapo-autogroup puts in full DNs as attribute values but my client programs (e.g. nss-ldapd) expect only a plain username to be there. In practical this means that I need to have that overlay to split the values of a particular type of attribute (like 'memberUid') and extract a particular part of it. You're misusing the schema here. The memberUid attribute is only for simple user IDs, not DNs. It would be very nice if it was possible to use regular expressions with backreferences for matching/rewriting the values or if there was a chance to 'plug in' an external program which accomplishes that job. (As far as i know slapo-rwm is only capable of rewriting dn's and attribute names etc. but no values, isn't it? So i need something else...) slapo-rwm rewrites DNs in DN-valued attributes as well. DN-valued meaning that the attribute's syntax is distinguishedName. It does not rewrite any other attributes. Thanks in advance! Tom -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Proxy cache overlay: effect of pcachePersist parameter?
Jonathan Clarke wrote:
Hi,
I've set up an ldap backend, with a pcache overlay to cache binds for PAM.
The config is below, for info.
My question concerns the pcachePersist parameter. From the man page:
pcachePersist { TRUE | FALSE }
Specify whether the cached queries should be saved across restarts of
the caching proxy, to provide hot startup of the cache. Only non-expired
queries are reloaded. The default is FALSE.
As I understand this, given pcachePersist FALSE (or not specified),
cached queries should no longer be in the cache after restarting slapd. Am
I right?
However, once a bind is successfully cached, I take the proxied server
offline and I can restart slapd many times, however my bind is still served
from cache.
Is this a bug in the docs, a bug in the implementation or just me not
getting something?
The proxycache writes all cached data into the cache DB. As such, cached
results are always present after a restart; this has always been the case.
That can be considered a bug, because it did not save any information about
the queries to which each cached entry belonged. So on a restart, the cache DB
contains stuff but the overlay doesn't know about it.
With pcachePersist set TRUE, the query info is also stored in the DB, and
re-loaded on restart. Thus the overlay will know the complete contents of the
cache DB.
Thanks,
Jonathan
PS: the simplified config:
8--
databaseldap
suffix dc=proxy
rootdn cn=manager,dc=proxy
uri ldap://my.other.ldap.server/
timeout 5
overlay pcache
pcache hdb 1 1 2 60
pcacheAttrset 0 *
# cache binds for 900 seconds = 15 minutes
pcacheTemplate (uid=) 0 900
pcacheBind (uid=) 0 900 sub dc=proxy
pcachePersist FALSE
pcacheOffline FALSE
directory /var/cache/ldap
cachesize 1
index objectClass,sAMAccountName,pcacheQueryideq
8--
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP for larger number of entries
Marcelo wrote: Hi, My organization works with public software, and we are interested in use OpenLDAP to control close of 100,000,000 users. Is it a good idea? What kind of database can we use? Is there some research that points what is the limit for the volume of users? Whether or not it is a good idea mostly depends on what you need to do with the data, and what software will be used to access it. If most of your apps already support LDAP then it's probably a good idea. There are no capacity limits in OpenLDAP. We have tested back-bdb and back-hdb with over 5 billion users. No other directory server in the world has scaled to sizes like this while delivering useful performance. The only limits are your own - your patience, and the performance of the machines you use to house the database. There are no secret tricks - good performance requires sufficient RAM and fast bandwidth to memory, disks, and network interfaces. Raw CPU performance is much less important here than aggregate bandwidth. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: rebinding and following referrals on bind
Arthur de Jong wrote: Hello list, Is there a way to follow a referral on bind? I'm trying to get the PAM module in nss-pam-ldapd to follow referrals while binding. Background is available here [1]. If ldapserver1 refers a subtree to another server (server2) searches for a user are correctly continued on server2 (using ldap_set_rebind_proc()) but when I try to call ldap_simple_bind_s() on the connection that just returned the user from server2 I get Invalid credentials. Is there a way to find out which LDAP server returned a specific entry or is there some other way to solve this? Just turn off automatic referral chasing and chase them manually. Then you'll know which server you're dealing with. Thanks for any pointes. [1] http://lists.arthurdejong.org/nss-pam-ldapd-users/2010/msg00097.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Kerberos userpassword storage
Indexer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
Im attempting to use Kerberos as a password storage backend in my ldap server.
I have the server setup with its own principal of the form
ldap/domainn...@realm , and this keytab is in the KRB5_KTNAME environment
variable as slapd starts.
I have put olcSaslRealm=REALM and olcSaslHost=kdc.domain into my cn=config.
Then, i have uid=user, where the userPassword attribute is {kerberos}u...@realm
Who told you to do that? There is no such password scheme in any OpenLDAP
documentation.
When attempting to bind to this user, it seems to fail. When i reset the
password to a standard SSHA hash, it authenticates correctly. I can
authenticate with kerberos to the host that the ldap enabled client, but i just
cannot use ldap with the kerberos password backend.
Any help in solving what else i need to do in this would be greatly appreciated
William Brown
pgp.mit.edu
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: PROBLEM: can't use SASL to authentication openldap client
Dan White wrote: On 09/08/10 16:56 +0800, LI Ji D wrote: Hi, My problem is that I expect slapd to authenticate with the password stored in sasldb. But it's not, it uses the password stored in userpassword attribute of this user which is a item of openldap. So I want to know, how can slapd use password stored in sasldb to do the sasl authentication. I attempted to do this as well and failed. Setting auxprop_plugin to sasldb did not provide the expected response. Regardless of whether I set it to slapd or sasldb, the server authenticates my digest-md5 sasl bind using the internal slapd plugin. I recommend you file a bug report. File the bug with the correct people. OpenLDAP doesn't do anything in particular with SASL configuration. If you can't get the desired behavior by setting the SASL config file, then file a bug against Cyrus SASL. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: syncrepl slaves all quit after master restart - not a single retry
Nick Urbanik wrote: Dear Alex, On 28/07/10 18:57 -0400, Alexander Ivanov wrote: Hello guys, I have a problem with delta-syn replication (all set up according to 'official' guide - http://www.openldap.org/doc/admin24/replication.html#Delta-syncrepl I'm running openldap 2.3.43-12.el5_5.1 from standard CentOS 5.4 installation. I am running the same openldap as you, on CentOS 5.5. It's generally a mistake to read the docs for a different version of the software than you're actually running. I have master instance with logs 'shipped' to a client - it all works fine as long as connection is good. Getting ready to move into production I'm trying to emulate connectivity problems and here where I got problems. [snip] once I have server disconnected (I sumply restart slapd on master), the client not even tries to re-connect, the log below shows modificatin operation at 18:34:18 that went fine and 11 seconds later I restart master's ldap service (which became immediately available again): I am having the same trouble, but with ordinary syncrepl. As soon as the master is restarted, the slaves all quit their syncrepl threads, and never start again: syncrepl rid=003 provider=ldap://master:389 type=refreshAndPersist bindmethod=simple binddn=cn=syncrepl,ou=tree,ou=name credentials=syncrepl-password searchbase=ou=tree,ou=name If you see any problems with these configuration files, please let me know, even if they do not relate to the problem of syncrepl terminating after master is restarted. You have no retry parameter in your syncrepl config, so naturally it does not retry. It always helps to actually Read The correct FM, slapd.conf(5) in your case. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: syncrepl slaves all quit after master restart - not a single retry
masar...@aero.polimi.it wrote: You have no retry parameter in your syncrepl config, so naturally it does not retry. It always helps to actually Read The correct FM, slapd.conf(5) in your case. I'd also note that slapd will issue syncrepl rid=003 searchbase=ou=tree,ou=name: no retry defined, using default if no retry is configured; one should at least wonder what that message means. I'd favor refusing to start if no retry is configured, since replication is not reliable without. That message was added in 2.4, these guys are using 2.3. At this point I've grown tired of telling people you're using an obsolete release, you should upgrade. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Notification of userPassword change in OpenLDAP?
Tom Leach wrote: I'm trying to work on a password sync scheme between OpenLDAP and some systems that use flat Unix passwd/shadow files. I have been able to update the LDAP server when someone changes their password on the standalone Unix systems, but I'm having problems trying to get any kind of notification from the LDAP server if someone from a system using the LDAP directory changes their password. So far, I'm looking at searching the LDAP directory every few minutes for any entries that have had their modifyTimestamp attribute change since the last time the search ran, then checking to see if the userPassword attribute in the LDAP directory is different then the shadow file on the Unix system. This seems like a real stupid scheme, especially when passwords are changed infrequently. I just don't want a long delay between syncing the directory and flat files in case someone changes their password on an LDAP client, then tries to log into the flat file system. Ideally, there could be some option in OpenLDAP that could call an external program when some attribute(s) have changed. That program could then perform the necessary searches and update the flat files if appropriate. So far, I've found nothing indicating that this is possible so I figured I'd ask and see if anyone else has tried this and what they found. Thanks! Tom Leach le...@coas.oregonstate.edu In the old Symas Connexitor EMS product we simply put a slapd on top of /etc/passwd, /etc/shadow, and /etc/group (that is, these flat files provide the backing store for the database that this slapd exposes) and then replicate account updates to it from a central master. You could accomplish much the same thing today using a client reading an accesslog DB. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Openldap2.4.16 performance issue
Singh, Devender (GE Capital, consultant) wrote: Hi Chu, Please help me on my below issue. It’s very urgent. If you have a support contract with us, you can contact us at supp...@symas.com for help. Otherwise, people help on this list as their time and interest allows. Thanks Regards,// *Devender Singh* Senior Unix Administrator,// *From:* openldap-technical-boun...@openldap.org [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of *Singh, Devender (GE Capital, consultant) *Sent:* Tuesday, August 17, 2010 5:12 AM *To:* openldap-technical@openldap.org *Subject:* Openldap2.4.16 performance issue Hi All, I need help for openldap slapd 200% cpu utilization issue. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Including schema in directory based config?
Quanah Gibson-Mount wrote: --On Wednesday, September 01, 2010 1:46 PM +0800 Will Dowling will+lists_openl...@autodeist.com wrote: I hope this makes sense and that someone is able to help me understand directory based configuration a little better. You can't just symlink them. You have to copy them over, and then edit the dn. No, you are never supposed to muck with any of the files inside slapd.d. You slapadd the LDIF files, same way you would load any other LDIF file into slapd. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Including schema in directory based config?
Will Dowling wrote: No, you are never supposed to muck with any of the files inside slapd.d. You slapadd the LDIF files, same way you would load any other LDIF file into slapd. Wow, okay. The online documentation doesn't make that clear at all (especially when it talks about converting your old config). http://www.openldap.org/doc/admin24/slapdconf2.html I'm not about to start picking fights with the Chief Architect though. Keeping that in mind - are you advocating this from a design point of view (it won't work properly), or a precautionary one (you shouldn't unless you know what you're doing)? If you know what you're doing, you can binary edit a BDB database file if you really want to. But most people don't want to, and certainly most people won't know what they're doing. cn=config is a slapd database and should be treated as such. The contents are not vanilla LDIF files, and database internals are always subject to change. It was designed to be used like other LDAP databases - using ldap* tools when slapd is running, and using slap* tools when slapd is offline. If it's the former (it won't work properly), can you make any recommendations for best-practice in terms of maintaining changes to third-party packaged configurations? For example, if we roll out updated schmea, would it be best to drop and re-add the schema - or diff the structure and create an update LDIF? Applying a diff via ldapmodify would be Best; that was the intended use case. Seems a bit clunky if thats the case, but I have had a few settings not stick already (olcDatabaseDirectory). Anyway, would love your insight and thanks for your time :) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: CRL refresh
Gianluigi Nigro wrote: Hi, Using version 2.4.23 with TLS. In slapd.conf the TLSCACertificatePath directive specifies the directory containing the certificate for the CA and the CRL. The content of this directory is hashed with c_rehash utilities. Everything works fine, but when a client certificate is revoked (ad a new CRL is created) i must restart the server to make it upgraded with the new CRL. Is there a way to do this, without having to reboot (a hot refresh of the CRL)? Thanks. gnigro There's no explicit mechanism to refresh the CRL. However, if you use cn=config and modify the TLS settings, it will reinitialize the entire TLS context, including reloading the CRL. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Authenticate to ldap using Kerberos
Wouter van Marle wrote:
On Wed, 2010-09-08 at 21:34 -0500, Dan White wrote:
On 09/09/10 10:21 +0800, Wouter van Marle wrote:
That requires pass-through authentication.
I see.
Well with the above instructions nothing seems to have changed.
I have restarted saslauthd and slapd after making the changes, and when
now accessing the ldap addressbook using Evolution, I still have to use
the ldap stored password, not the krb password.
Wouter.
To be a little more explicit, to enable pass-through authentication, you
will need to replace the password (userPassword attribute) with:
userPassword: {sasl}usern...@realm
When I got it working I am considering to write some tutorial - maybe
useful. I haven't been able to find anything like it on the internet.
The above I have never seen; just once a suggestion to change the
password to {KERBEROS}username but well that also didn't work :)
It's much harder to get working than I ever expected, really. And even
more so I'm surprised that openldap doesn't support this out of the
box, or with some minor settings.
It is not supported out of the box because it's generally the wrong thing to
do. It is intentionally undocumented, to discourage people from pursuing this
misguided course. Use GSSAPI.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Authenticate to ldap using Kerberos
Dan White wrote: On 09/09/10 20:05 -0700, Russ Allbery wrote: Wouter van Marlewou...@squirrel-systems.com writes: At this moment, I can connect to my ldap server from Evolution, authenticated. I have to enter a username and a password in my evo settings, which one way or another is communicated to openldap, which then checks this un/pw combo and considers it valid to give the information. If you are using Kerberos, you should never have to enter your username and password into anything that isn't kinit or your initial authentication to your system. If you do, that something is broken and is not using Kerberos properly. Period. So if the poster had stated that he wanted to perform PAM authentication for his simple binds, I don't think he'd be confronted with such a violent reaction. However, from the standpoint of slapd, that's exactly what he's wanting to do. Performing simple binds have precisely the same negative security footprint regardless of where his passwords may be stored. I'm assuming Evolution No, it makes a difference, and the fact that you're not aware of the difference demonstrates that you haven't thought it through enough to be qualified to render an opinion on it. Kerberos is secure precisely because client passwords are never transmitted across the network. Period. When you break that guarantee, everything else about the Kerberos system is jeopardized, and typically, when Kerberos is in use at a site, there's a large ecosystem of apps dependent on it and all of their security goes down the drain at the same time. supports ldaps or STARTTLS, which would go a long way in mitigating that risk. If it didn't support TLS, I'd think that'd be a much more urgent ldaps or TLS might be ok, assuming you're not using a broken SSL implementation. Abusing Kerberos in the requested way and relying on other security systems to take up the slack is opening yourself up to a whole world of unintended consequences, and we need only look at Debian last year to see how real those problems may be. focus (GSSAPI only provides 56 bits of encryption). The strength of GSSAPI's encryption layer is irrelevant in this discussion since, when used properly, it NEVER exposes the client's secret key to anybody else. SASL is what you do when you implement Kerberos properly. Evolution is not doing this. It's either implementing a broken version of SASL where it only implements a single mechanism (PLAIN), or it's actually not doing SASL at all (most likely). The problem is exactly that Evolution is not properly implementing Kerberos SASL mechanisms. Would you agree that any application which does not support the full range of SASL mechanisms is broken? What about simple binds? Would you suggest that OpenLDAP remove all support for simple binds? If not, why not? RFC4513 pretty much deprecates Simple Binds. Certainly it discourages using them on an unprotected session, and the OP has already stated that he has yet to get TLS working. And applications don't have to implement specific SASL mechanisms, that's all hidden inside libldap and libsasl2. All they have to do is use the right libldap calls and they automatically get support for all mechanisms, currently known as well as future mechs. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: invalid syntax on pwdPolicy object add
mailing lists wrote: Hello, I think that the pwdAttribute needs an OID value (specified by the syntax) so you would must use the OID of the userPassword attribute which is 2.5.4.35 This is true if you don't have the ppolicy module loaded. When the module is loaded, it installs a custom syntax handler for the pwdAttribute attribute that will recognize textual attribute names as well as OIDs. If you don't have the module loaded, you have done something wrong. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to slapadd cn=config
Torsten Schlabach (Tascel eG) wrote: Dear list! If I have an LDIF backup of a cn=config database, taken with slapcat, how would I use it to bootstrap a new server, for example, in a desaster recovery setting? I tried it and slapadd required a configuration, but cn=config *is* the configuration and I am trying to restore it. So this is a bit of a chicken and egg problem, isn't it? It looked that way, when we started designing this 4 years ago. But yes, we have a solution. Is there an official way of doing that? Exactly the same way as you slapcat'd it. What was the exact command line you used for slapcat? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: MoNSS support in openldap
Quanah Gibson-Mount wrote: --On Friday, September 24, 2010 7:25 PM +0200 Silvan Marco Fin sil...@kernelconcepts.de wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Is there any magic to be cast upon openldap to enable the MozNSS support when compiling it? Perhaps I'm missing something, but there doesn't seem to be a configure switch to enable NSS, like with Gnutls or OpenSSL. There is no switch for it at this time. And that is because currently MozNSS cannot be used transparently as a drop-in replacement for OpenSSL or GnuTLS. Once the MozNSS folks get their PEM handler into their mainline code, it ought to work reasonably transparently, and at that point we may provide a configure switch for it. For now, we do not endorse or support it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: MoNSS support in openldap
Silvan Marco Fin wrote: Thanks for your input, currently I'm trying to get it working with the description supplied here. Am 27.09.2010 22:38, schrieb Howard Chu: doesn't seem to be a configure switch to enable NSS, like with Gnutls or There is no switch for it at this time. And that is because currently MozNSS cannot be used transparently as a drop-in replacement for OpenSSL or GnuTLS. Once the MozNSS folks get their PEM handler into their mainline code, it ought to work reasonably transparently, and at that point we may provide a configure switch for it. For now, we do not endorse or support it. Perhaps I can give you some additional reason to support NSS: MozNSS has the certdb thing and PKCS11 support. We (that is my company: kernel concepts) want to get evolution's ldap backend to support client side certificates from software and hardware tokens and that is exactly, what MozNSS provides out of the box. OpenSSL currently lacks PKCS11 support completely (AFAIK) and Gnutls support for PKCS11 is very new, so our goal is, to get everything we need out of NSS. OpenSSL has had PKCS11 support since at least 2001. It's usually packaged by distros and ready to use, e.g. https://launchpad.net/ubuntu/karmic/+package/libengine-pkcs11-openssl MozNSS still has serious design problems wrt reentrancy and multiple independent code bases (programs and libraries) calling into it with different config requirements... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: meta backend olc?
Marc Patermann wrote:
Hi,
while migrating servers form 2.3.x to 2.4.x I stumbled upon this with
openldap2-2.4.20-0.4.29 SLES11SP1.
When I try online config based on my slapd.conf file, I get an error
# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d -u
config file testing succeeded
fine so far.
# slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d
WARNING: No dynamic config support for database meta.
WARNING: No dynamic config support for database meta.
WARNING: The converted cn=config directory is incomplete and may not work.
...
cn=config # cat olcDatabase={1}meta.ldif
dn: olcDatabase={1}meta
There is no URI or any meta specific attribute here.
Of course not, because it is not supported. Does your question indicate that
the above warning messages are not clear enough? How can we make them clearer?
from slapd.conf:
databasemeta
suffix ou=AllgV,ou=foo
uri ldap://server/ou=AllgV,ou=foo;
suffixmassage ou=AllgV,ou=foo ou=allgv,ou=proxy,o=bar
conn-ttl 30
idle-timeout 1m30s
subordinate
Is there something wrong with my config or does meta not work with olc?
According to the mail from p.
http://www.openldap.org/its/index.cgi/Documentation?expression=meta;download=Documentation/6277.followup.1.eml
it seems to be not me.
Whereas Howard replied: All of the core overlays now support
cn=config.
http://www.openldap.org/its/index.cgi/Documentation?id=6277;expression=meta#themesg
Exactly so. meta is a backend, not an overlay, and I specifcally said overlays.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How can I make the unique overlay play nicely with my ACL?
Owen Jacobson wrote: Hi there, I'm trying to enforce that the 'uid' attribute is globally unique in my tree using the unique overlay. For a collection of mostly-uninteresting reasons, the LDAP server is publicly connectable but not publicly searchable (details below). It appears that the unique overlay uses the *worst possible* combination of credentials to perform the searches it uses to guarantee uniqueness. All of the following information was obtained from ldapsearch -Y EXTERNAL -H ldapi:/// -b cn=config -- it's really what slapd thinks it's seeing. As you can see, (a) the IP address the search comes from is not the IP address of the LDAP server nor is it the LDAP server's ldapi:// socket (it's actually my client machine's IP address) and (b) the authenticated DN used in the search is empty. Combined, these two facts lead to slapd deciding the search is not permitted by the ACL, which in turn causes the unique overlay to decide no other entries with the same uid exist. This seems wrong: the connection from that IP and port has already authenticated as a user (which would've permitted the search). Assuming for the moment that allowing the world at large to search my LDAP server is not an option, how can I allow the unique overlay to enforce my constraint? Re-read the slapo-unique(5) manpage. Specifically the 3rd paragraph. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Asynchronicity
William Ahern wrote: Excepting DNS, is the latest release of OpenLDAP fully asynchronous-capable, even with TLS? Perusing the source code I can't find any obvious places other than DNS where things might block, but it's harder to prove the negative. I remember many years ago this wasn't the case, and I had to thread the connect phase, but the ChangeLog suggests that things have changed considerably. Connect has been asynch for years, though an option to configure the connect timeout is a more recent addition. The only significant thing left that I can think of that's still only synchronous is ldap_sasl_interactive_bind_s(), and I have some plans to fix that. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: support for arbitrary PKCS11 pin input method
Rich Megginson wrote: Silvan Marco Fin wrote: Hi! I searched through tls_m.c for means to enter the token PIN for a PKCS11 token. I found a call to PK11_SetPasswordFunc(). The callback is set to tlsm_pin_prompt(), which by itself uses tlsm_get_pin(). tlsm_get_pin() only supports reading the PIN from file or via STDIN. To be usable within any form of gui, there would have to be some method to pass a GUI callback to ask for the PIN. How would this work? Would you pass in a callback function with your private context, and this callback function would be called with the current MozNSS context + your provided context? What would be the possible return values from your callback? What should the code do depending upon each return value? Is there currently a way, via the OpenLDAP API, to pass in such a function and context? For what it's worth, we need to add this feature for sasl_interactive_bind as well. Thus far, for the ldap_sasl interface all of the callback parameters have been passed on the function invocation, as opposed to being set by a separate ldap_set_option(). It makes for a clunky function signature, but seems safest in terms of re-entrancy... Do you plan on implementing such a feature in the near future or is there a proposed way of setting such a callback method? Kind regards, Silvan -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to configure overlay unique in cn=config
Buchan Milne wrote: On Thursday, 14 October 2010 21:23:05 Benjamin Griese wrote: Hey buddy, if you use Apache Directory Studio amongst other things for configuring overlays, it automatically gets you the right dependencies if you choose for example OC olcUnique, you need also need to have OC olcOverlay and so on, ADS automatically sets it for you in a wizard like process. Doing that without that tool was really a PITA, especially if are not that familiar with the whole package of different types of classes and schema dependencies. Give it a try, ADS made my life as LDAP-Admin a whole lot of easier. Unfortunately, I don't think there is any way to know (over LDAP) whether the unique module is built-in, compiled as a module, or not compiled at all, so I don't believe ADS can help in this situation ... The Samba folks were complaining about this ambiguity a while back. Which is why we recommended that they just always issue the moduleload statements. They will be ignored/no-op'd if the module was already built in. Likewise, the default modulepath is always compiled in, so there's no need to set it unless you're loading a custom module of your own from some other location. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Possible bug in ldap_get_values_len?
Edward Z. Yang wrote: Hello all, I was mucking around with OpenLDAP and noticed that ldap_get_values_len was returning NULL without setting a corresponding error code. Intruiged by this behavior, I did some debugging, and found that it was doing so on nsslapd-referral as generated by a Fedora 1.2.5 or 1.2.6 directory server for the cn=config entry (I haven't checked anywhere else yet). Here is a fragment of the byte sequence in ber_buf that was causing this: 000140410nsslapd-referral1000190412password I checked some other code, ldapvi works around this by checking if the return value of ldap_get_values_len is NULL before using it, but it doesn't seem to do so consistently, and an old version of the code had this to say: struct berval **values = ldap_get_values_len(ld, entry, ad); struct berval **ptr; if (!values) continue; /* weird server */ I've also posted to 389-users [1], in Fedora Directory Server spitting out malformed data. But in that case, OpenLDAP should give me an error code, or work around it, or something. Looking at the code and your data snippet, this is because your BER sequence says it's got a set of zero values. In this case, ber_scanf doesn't bother to allocate any memory to store the values, since there would be no point. Technically there's no error here; sets are allowed to be empty. (E.g., if you had done an attrsOnly search then all of the attributes would have zero sets for their values.) So no, it's not a bug that libldap returns NULL instead of a pointer. And no, libldap shouldn't report an error code here either. But it's certainly stupid for the server to attach the attribute to the response with no values, since this is obviously NOT an attrsOnly search response. Sounds like you ought to file a bug report against the Fedora Directory Server. Cheers, Edward [1] http://lists.fedoraproject.org/pipermail/389-users/2010-October/012320.html -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Possible bug in ldap_get_values_len?
Edward Z. Yang wrote: Excerpts from Howard Chu's message of Mon Oct 18 15:23:02 -0400 2010: The function would return a zero-length berval in that case. There's a difference between no values, and one value of zero length. Sure, but for the programmer, there is definitely a difference between p == NULL and *p == NULL. :-) Of course. And again, that's a one-to-one mapping to the difference between no values (p == NULL) and one value of zero-length. Since both conditions are legal in the ASN.1 data, as a programmer you must handle both. (Even though it's nonsensical in this context, and the server is clearly broken.) -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Configuring OpenLDAP 2.2 with gdbm
Benjamin Griese wrote: Hi Prentice, in general you're right I wouldn't say something if he had a release in the lower 2.4s, but the version he is using is _two major_ releases behind. Probably when he fixed his original problem, its not too far away to think of the next problem due to a bug thats already fixed in a newer version. Thats the only point I was thinking of by saying that. Not to mention that gdbm was never a safe DB mechanism, it has a lot of thread safety issues. No matter what, sticking with it would be a mistake. And nobody on the Project will support anything that old. We've already dropped support for 2.3 now; if you're not on 2.4 by now then don't bother posting to these lists. Bye. On Mon, Oct 18, 2010 at 15:46, Prentice Bisbalprent...@ias.edu wrote: Benjamin, Telling someone to upgrade their software just because it's an older version is not an appropriate response. It looks like the configure script can't find the ldbm library, so even if he upgraded to teh latest version, if he doesn't correct his environment, he may still have the same error. Prentice Benjamin Griese wrote: Hello Piotr, you should consider updating your ancient OpenLDAP-Server. :) Bye, Benjamin. On Mon, Oct 18, 2010 at 14:14, KALINOWSKI, Piotr (Piotr) piotr.kalinow...@alcatel-lucent.com wrote: Hello, I am trying to build OpenLDAP version 2.2.17 with the gdbm back end. The platform is Solaris 10 on SPARC. However, the configure script fails with the following error: ./configure --enable-ldbm --with-ldbm-api=gdbm --enable-shell --enable-crypt --disable-bdb ... checking for GDBM library... checking for gdbm_open... no checking for gdbm_open in -lgdbm... no no checking for gdbm.h... yes checking for db... no configure: warning: could not find suitable LDBM backend configure: error: select appropriate LDBM options or disable Does anyone know how to fix it? Thanks in advance. Piotr -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: db stick in RAM ?
Frank Bonnet wrote: Hello I'm thinking to put db files in RAM instead of hard disk for performance reasons. FreeBSD ( and Linux thought ) provide some utility to build RAMDISK ( md ) I did some tests in rebuilding db files with the slapcat/slapadd commands with RAMDISK ldap3# time slapadd -l test.ldif /usr/local/etc/openldap/slapd.conf: line 110: rootdn is always granted unlimited privileges. 100.00% eta none elapsed 20s spd 633.9 k/s WITH HARDDISK ldap3# time slapadd -l test.ldif /usr/local/etc/openldap/slapd.conf: line 110: rootdn is always granted unlimited privileges. 100.00% eta none elapsed 04m22s spd 48.4 k/s Does anyone runs production servers with ramdisk ? I know it is risky but running rsyncd between ramdisk and a hardisk depot would be safe huh ? Thanks for any advices No, I wouldn't do this, but I would run with the BDB cache in shared memory instead of on disk. It won't survive a system crash/reboot, but otherwise it's superior for performance. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: db stick in RAM ?
Frank Bonnet wrote: Hello Yes maybe safier to use slapcat ... I haven't any SSDs for now so I tested ramdisk did you perform tests with SSD ? A good SSD can work, but it will cost quite a bit and RAM is still an order of magnitude faster. Also, most of the SSDs available now are still poor for random writes, which is the main performance bottleneck. (All of my PCs are on SSDs now; they're great for fast boot times but without a big RAM cache they're still dog slow.) thanks On 10/19/2010 11:00 AM, Benjamin Griese wrote: Hi Frank, by rsync to hdd, do you mean copying the db files or slapcat the output to a file? The first one seems to be a db killer if the db is in use while copying it. :) I think the only safe way is by doing a slapcat after every write to the db (accesslog?). Anyway, sounds like a nice idea to me to get a big performance boost. Have you considered SSDs instead of ramdisks? Imo its the more safe and nearly as fast as ramdisk alternative. :) Bye, Benjamin. On Tue, Oct 19, 2010 at 10:40, Frank Bonnetf.bon...@esiee.fr wrote: Hello I'm thinking to put db files in RAM instead of hard disk for performance reasons. FreeBSD ( and Linux thought ) provide some utility to build RAMDISK ( md ) I did some tests in rebuilding db files with the slapcat/slapadd commands with RAMDISK ldap3# time slapadd -l test.ldif /usr/local/etc/openldap/slapd.conf: line 110: rootdn is always granted unlimited privileges. 100.00% eta none elapsed 20s spd 633.9 k/s WITH HARDDISK ldap3# time slapadd -l test.ldif /usr/local/etc/openldap/slapd.conf: line 110: rootdn is always granted unlimited privileges. 100.00% eta none elapsed 04m22s spd 48.4 k/s Does anyone runs production servers with ramdisk ? I know it is risky but running rsyncd between ramdisk and a hardisk depot would be safe huh ? Thanks for any advices -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Jndi VLV usage (maybe a BER encoding issue)
Please read http://www.openldap.org/devel/contributing.html This mailing list is not for patch submissions. Sebastien Bahloul wrote: Hi, Does anyone already succeed to use VLV search requests through JNDI API ? It is functional with ldapsearch, but I get the following error on JDK 1.5 : -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Attribute Aliasing
Russell Harmon wrote: On Tue, Oct 26, 2010 at 22:37, Dieter Kluenterdie...@dkluenter.de wrote: Russell Harmonr...@eatnumber1.com writes: I'm trying to reconfigure my existing OpenLDAP server to expose personal information under multiple attributes. I'm doing this so that both Apple's contact application and my custom software will work. I've read about rwm-map in slapo-rwm, but although it makes the new attribute accessible, it hides the old one. I need both the new and old to be accessible. For example: I have an existing attribute for a cellular phone number cellPhone. I want to make this accessible under both the attributes cellPhone and mobile Is this possible with OpenLDAP? either include the evolution.schema or create your own schema and define mobileTelephoneNumber superior to cellPhone. That seems to work only so far as searching for the attribute mobile will return the attribute cellPhone. I need it to return the data in the attribute cellPhone as the attribute mobile. 1) fix your custom software to use configurable schema, and configure it to use the same as Apple's. or 2) use back-relay, and point your software at one database and the Apple software at the other database, and rewrite as appropriate for each app. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Alias dereferencing
Ryan Steele wrote: I'm trying to implement some aliases for several groups in my directory to provide a bit of aesthetics for a few applications that leverage the OpenLDAP users and groups. However, I seem to be running in to a little trouble, perhaps because I'm expecting alias dereferencing to do something it wasn't really designed to do. For reference, this is 2.4.21, but I was able to test on a 2.4.23 database with the same results. I'm using the autogroup module as well for some pseudo-static dynamic groups. Consider the following basic DIT and abbreviated set of entries (abbreviated entries denoted by '...'): Your problem has nothing to do with alias dereferencing. dn: cn=sysadmins,ou=Groups,dc=example,dc=com objectClass: top objectClass: groupOfURLs objectClass: posixGroup memberURL: ldap:///ou=Users,dc=example,dc=com?dn?sub?((objectClass=examplecomEmployee)(departmentName=sysadmins)) member: uid=john,ou=Users,dc=example,dc=com member: uid=jane,ou=Users,dc=example,dc=com member: uid=joe,ou=Users,dc=example,dc=com ... dn: cn=Systems Administrators,ou=Groups,dc=example,dc=com ou: Groups cn: Systems Admins objectClass: alias objectClass: extensibleObject aliasedObjectName: cn=sysadmins,ou=Groups,dc=example,dc=com When I initiate an ldapsearch and choose not to dereference, I see what I expect: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a never -b dc=example,dc=com cn=Systems\ Administrators dn: cn=Systems Administrators,ou=Groups,dc=example,dc=com ou: Groups objectClass: alias objectClass: extensibleObject aliasedObjectName: cn=sysadmins,ou=Groups,dc=example,dc=com cn: Systems Administrators However, when I do choose to dereference, nothing is returned: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a find -b dc=example,dc=com cn=Systems\ Administrators j...@ldap1:~# j...@ldap1:~# ldapsearch -x -ZZ -LLL -a always -b dc=example,dc=com cn=Systems\ Administrators j...@ldap1:~# Clearly the result you got is correct. I can only obtain the expected results if I set the search base to the *specific* entry I'm looking to dereference: j...@ldap1:~# ldapsearch -x -ZZ -LLL -a always -b cn=Systems\ Administrators,ou=Groups,dc=example,dc=com dn: cn=sysadmins,ou=Groups,dc=example,dc=com ou: Groups gidNumber: 4001 cn: sysadmins objectClass: groupOfURLs objectClass: top objectClass: posixGroup description: The sysadmin team members memberURL: ldap:///ou=Users,dc=example,dc=com?dn?sub?((objectClass=examplecomE mployee)(departmentName=sysadmins)) member: uid=john,ou=Users,dc=example,dc=com member: uid=jane,ou=Users,dc=example,dc=com member: uid=joe,ou=Users,dc=example,dc=com I find it hard to believe that setting the search base to the alias entry is the only way which one may reference the alias entry And that is clearly not the case, in fact. Your last search is not equivalent to your previous searches, because the last time you omitted the **SEARCH FILTER**. Think about it. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: unable to perform authenticated binds
Chris Jacobs wrote: Ya know, that leading space thing confused the heck out of me when I started writing a slapf.conf from scratch. I'm guessing were ya'll to know at that start of spec'ing slapd.conf the methods that are now common to multi-line or 'containerize' options, something different, more readable, and less error (yes, user error) prone would have been selected. Really, white space shouldn't kill a config. Hindsight, eh? Indeed, thanks so much for the exceedingly useful insight. The practice was established long before I joined the Project. Enough people whine about all the other insignificant, backward-compatible changes we make that changing this is obviously a non-starter. The use of whitespace is clearly described in the manpage and the Admin Guide. People who don't read the manpage deserve no sympathy. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: unable to perform authenticated binds
Howard Chu wrote: Chris Jacobs wrote: Ya know, that leading space thing confused the heck out of me when I started writing a slapf.conf from scratch. I'm guessing were ya'll to know at that start of spec'ing slapd.conf the methods that are now common to multi-line or 'containerize' options, something different, more readable, and less error (yes, user error) prone would have been selected. Really, white space shouldn't kill a config. Hindsight, eh? Indeed, thanks so much for the exceedingly useful insight. The practice was established long before I joined the Project. Since long before the Project existed, actually. Enough people whine about all the other insignificant, backward-compatible changes we make that changing this is obviously a non-starter. The use of whitespace is clearly described in the manpage and the Admin Guide. People who don't read the manpage deserve no sympathy. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Syncprov checkpoint and sessionlog with cn=config
Jaap Winius wrote: Quoting Howard Chuh...@symas.com: Jaap Winius wrote: .. but these configuration attributes are not well documented yet, at least not for cn=config. They're not yet included in the slapo-syncprov man page and (correct me if I'm wrong) the online documentation doesn't seem to mention them either. They are simply LDAP schema elements. Their definitions are always present in the directory itself. Okay, at least there's that, but if not in man slapo-syncprov, then I was kind of hoping/expecting that this information would be included in Chapter 18 (Replication) of the online documentation. That page already mentions the slapd.conf versions of these directives, but not the ones for cn=config. They could at least be included in one of the cn=config examples there. You're welcome to submit a patch for the docs. As lead developer on the Project I focus on working on the things that would be difficult for anyone else to do. For stuff like this where the information is already available, it's up to the rest of the community to fill in. % ldapsearch -x -H ldap://:9011 -D cn=config -W -b cn=schema,cn=config -s base | grep -A 2 OLcfgOv..:1 People who understand LDAP don't need to be reminded of things like this. They already understand that LDAP-based configuration means that everything is already part of the LDAP schema, and LDAP schema is self-describing so no external document is absolutely required. (Conversely, people who grumble that LDAP-based config is too complicated and a bad idea simply don't understand LDAP...) Very handy! Thanks, Jaap -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: unable to perform authenticated binds
Quanah Gibson-Mount wrote: --On Wednesday, November 03, 2010 6:09 PM -0400 Tim Dunphy bluethu...@gmail.com wrote: holy crap!! it was the extra colon that killed it! found it, fixed it.. man oh man sorry for the intrusion! Yeah, :: on userPassword means it is base-64 encoded already, and clearly that bit of LDIF was not base-64 encoded. ;) And again, stuff like this is clearly documented in the ldif(5) manpage... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Asynchronicity
Shankar Anand R wrote: Hi, Is there any workaround way by which we will be able to do a DIGEST-MD5 - SASL LDAP bind asynchronously? Howard: Is there a plan to have an asynchronous ldap_sasl_interactive_bind in the near future? Any time lines for that? No future plan. It's in CVS as of October 13, so it's already in the past. Thanks, Shankar On Mon, Oct 11, 2010 at 3:06 PM, Howard Chu h...@symas.com mailto:h...@symas.com wrote: William Ahern wrote: Excepting DNS, is the latest release of OpenLDAP fully asynchronous-capable, even with TLS? Perusing the source code I can't find any obvious places other than DNS where things might block, but it's harder to prove the negative. I remember many years ago this wasn't the case, and I had to thread the connect phase, but the ChangeLog suggests that things have changed considerably. Connect has been asynch for years, though an option to configure the connect timeout is a more recent addition. The only significant thing left that I can think of that's still only synchronous is ldap_sasl_interactive_bind_s(), and I have some plans to fix that. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to convert Solaris m5 passwords to LDAP?
Christian Schmidt wrote:
Hi all,
we want to switch a server machine from Solaris (credentials stored
in traditional passwd and shadow file) to Debian with OpenLDAP for
authentication.
Creating LDIF files from /etc/passwd and /etc/shadow using PADL's
migrationtools is working fine. The only problem is, that many user
passwords on the Solaris machine have been encrypted using Sun's md5 scheme
which results in hashes beginning with the characters $md5$.
These hashes can be imported into our LDAP directory, but
they cannot be used for authentication: Each attempt results in
access denied on the client side and LDAP bind errors on the server
side. Even when adding the user information to /etc/passwd and
/etc/shadow on the Linux machine, there's no success.
With CRYPT password hashes, everything works fine.
Do you know any means to convert these Solaris-md5-hashed
password strings into something we can use with OpenLDAP?
I appreciate your helpful answers. Thanks in advance!
No conversion is necessary, as long as you built OpenLDAP with --enable-crypt
and you're using the native C library's crypt() (and not e.g. OpenSSL's
crypt()) and the password is stored with the {crypt} tag. (And the slapd is
actually running on Solaris.)
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: ldapsearch performance degradation
Tim Dyce wrote: Hi Dieter, Thanks for the tips on tuning, sadly the problem is still haunting us :( Andrey Kiryanov at CERN has been doing a lot of work on this performance degradation problem as well. He has tried BDB 4.8.30 and OpenLDAP 2.4.23 but the problem is still apparent. I've run the test setup you provided here http://www.openldap.org/lists/openldap-technical/201010/msg00237.html but so far I'm seeing constant (0:00.0 second) results from ldapsearch. Some differences - I used back-hdb, which is going to be superior for a heavy add/delete workload. Also my test DB is running on a tmpfs (RAMdisk). The basic test we are running (sent earlier) creates 100 ou entries in the root, each with 250 child ou entries, then deletes 20-35% of these and re-adds them. For each deletion cycle the ldapsearch performance degrades, taking longer to complete the search each time. The performance is consistent, across restarts of slapd, and tied to the current state of the database. I have tried rsyncing out the database, and returning it later, and the performance is consistent with the number of deletion cycles the database has undergone. The only clue I have is that when dumping the databases which db_dump it's clear that the ordering of the database becomes increasingly less aligned with the order of the output data when doing a full tree search as we are. Which suggests that the database is writing frequently accessed entires too often instead of holding them in cache? I have run cachegrind against the server at 2, 20 and 1000 deletion iterations and the results are very different - http://www.ph.unimelb.edu.au/~tjdyce/callgrind.tar.gz The number of fetches grows massively over time. Anything you guys can suggest would be much appreciated, it's started to affect quite a number of our grid sites. Cheers, Tim On 04/11/10 02:56, Dieter Kluenter wrote: Hi Dieter, I've done some more testing with openldap 2.3 and 2.4, on Redhat and Ubuntu. I even went as far as placing the BDB database directory in a ramdisk. But the performance still seems to degrade over time as data is added then deleted repeatedly from the ldap server. It looks like the BDB database starts to fragment or lose structure over time? I've tried a few DB options that seem to have some impact. Any ideas on what I can do from here? Quite frankly, I have no clue, all i can do is guessing. First let's define the problem: you have measured the presentation of search Results the client side, and you observered an increase of time required to present the results. Mostlikely it is either a caching problem, a disk problem or a network problem. As far as openldap related, there are four caches to watch: 1. the bdb/hdb database (DB_CONFIG, cachesize) 2. the DN cache (dncachesize) 2. the cache of searched and indexed attribute types (idlcachesize) 3. the frontside cache of search results (cachesize) please check slapd.conf whether appropriate sizes are configured, see man slapd-bdb(5) and slapd.conf(5) for more information. But I must admit, a misconfiguration of any of this caches would not lead to such a degrading in presenting search results. An other approach would be to check the caching behaviour of clients, to check the network cache and the disk cache. -Dieter -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: ldapsearch performance degradation
Tim Dyce wrote: Hi Howard, Thanks for the help :D We have been testing in ramdisk as well, to make sure that disk thrashing is not the root cause. If your searches are not running long enough to show up for profiling, increase the number of second level entries until you get something you can profile. Ah, there's a bug in your script, it's creating the 2nd-level entries with the wrong DN so the DB never had more than 250 entries. Now I've fixed that and run again and can see the behavior you're talking about. It's actually due to a particular design choice: Ordinarily at each level of the tree we keep an index tallying all of the children beneath that point. In back-bdb this index is used for subtree searches and for onelevel searches. (In back-hdb it's only used for onelevel.) However, as a write optimization, for the root entry of the DB, we don't bother to maintain this index, it's simply set to All entries. (Otherwise in the back-bdb case, there is far too much write overhead to maintain this index.) The problem is that All entries is actually a range 1 to N where N is the ID of the last entry in the DB. (And 1 is the ID of the root entry.) As you add entries, N keeps increasing, but 1 stays constant. When you do a subtree search, every entryID in the corresponding index slot is checked. In this case, with a subtree search starting at the root entry, you will always be iterating through every ID from 1 thru N, even though many of those IDs have been deleted, and it takes time for BDB to return no such object for all the deleted IDs. If you do all of your operations under a child entry instead of the database root entry, the performance will be constant. I've already verified this with a modified copy of your test. I can post it if you wish. Thanks Tim On 11/11/10 21:38, Howard Chu wrote: Tim Dyce wrote: Hi Dieter, Thanks for the tips on tuning, sadly the problem is still haunting us :( Andrey Kiryanov at CERN has been doing a lot of work on this performance degradation problem as well. He has tried BDB 4.8.30 and OpenLDAP 2.4.23 but the problem is still apparent. I've run the test setup you provided here http://www.openldap.org/lists/openldap-technical/201010/msg00237.html but so far I'm seeing constant (0:00.0 second) results from ldapsearch. Some differences - I used back-hdb, which is going to be superior for a heavy add/delete workload. Also my test DB is running on a tmpfs (RAMdisk). The basic test we are running (sent earlier) creates 100 ou entries in the root, each with 250 child ou entries, then deletes 20-35% of these and re-adds them. For each deletion cycle the ldapsearch performance degrades, taking longer to complete the search each time. The performance is consistent, across restarts of slapd, and tied to the current state of the database. I have tried rsyncing out the database, and returning it later, and the performance is consistent with the number of deletion cycles the database has undergone. The only clue I have is that when dumping the databases which db_dump it's clear that the ordering of the database becomes increasingly less aligned with the order of the output data when doing a full tree search as we are. Which suggests that the database is writing frequently accessed entires too often instead of holding them in cache? I have run cachegrind against the server at 2, 20 and 1000 deletion iterations and the results are very different - http://www.ph.unimelb.edu.au/~tjdyce/callgrind.tar.gz The number of fetches grows massively over time. Anything you guys can suggest would be much appreciated, it's started to affect quite a number of our grid sites. Cheers, Tim On 04/11/10 02:56, Dieter Kluenter wrote: Hi Dieter, I've done some more testing with openldap 2.3 and 2.4, on Redhat and Ubuntu. I even went as far as placing the BDB database directory in a ramdisk. But the performance still seems to degrade over time as data is added then deleted repeatedly from the ldap server. It looks like the BDB database starts to fragment or lose structure over time? I've tried a few DB options that seem to have some impact. Any ideas on what I can do from here? Quite frankly, I have no clue, all i can do is guessing. First let's define the problem: you have measured the presentation of search Results the client side, and you observered an increase of time required to present the results. Mostlikely it is either a caching problem, a disk problem or a network problem. As far as openldap related, there are four caches to watch: 1. the bdb/hdb database (DB_CONFIG, cachesize) 2. the DN cache (dncachesize) 2. the cache of searched and indexed attribute types (idlcachesize) 3. the frontside cache of search results (cachesize) please check slapd.conf whether appropriate sizes are configured, see man slapd-bdb(5) and slapd.conf(5) for more information. But I must admit, a misconfiguration of any of this caches would not lead
Re: ldapsearch performance degradation
Howard Chu wrote: Tim Dyce wrote: Hi Howard, Thanks for the help :D We have been testing in ramdisk as well, to make sure that disk thrashing is not the root cause. If your searches are not running long enough to show up for profiling, increase the number of second level entries until you get something you can profile. Ah, there's a bug in your script, it's creating the 2nd-level entries with the wrong DN so the DB never had more than 250 entries. Now I've fixed that and run again and can see the behavior you're talking about. It's actually due to a particular design choice: Ordinarily at each level of the tree we keep an index tallying all of the children beneath that point. In back-bdb this index is used for subtree searches and for onelevel searches. (In back-hdb it's only used for onelevel.) However, as a write optimization, for the root entry of the DB, we don't bother to maintain this index, it's simply set to All entries. (Otherwise in the back-bdb case, there is far too much write overhead to maintain this index.) The problem is that All entries is actually a range 1 to N where N is the ID of the last entry in the DB. (And 1 is the ID of the root entry.) As you add entries, N keeps increasing, but 1 stays constant. When you do a subtree search, every entryID in the corresponding index slot is checked. In this case, with a subtree search starting at the root entry, you will always be iterating through every ID from 1 thru N, even though many of those IDs have been deleted, and it takes time for BDB to return no such object for all the deleted IDs. If you do all of your operations under a child entry instead of the database root entry, the performance will be constant. I've already verified this with a modified copy of your test. I can post it if you wish. Just for sake of comparison with your original test setup from http://www.openldap.org/lists/openldap-technical/201010/msg00237.html I tweaked the DB_CONFIG parameters to speed up the ldapadds, otherwise it takes too long to run the test. Your cache sizes etc. were all too small... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ newtest.tar.gz Description: GNU Zip compressed data
Re: ldapsearch performance degradation
Tim Dyce wrote: Hi Howard Thank you very much! This explains a *lot* :D For the moment however we have 370 facilities using this information system, and sadly a whole bunch of scripts which will do thier ops from the base. Is there anything else you can suggest we do to work around this? The cheapest workaround is to change your DB config to have an empty suffix. Then the DN is the DB root entry, and your ou=test will be the first child entry. (You'll have to reload the DB of course.) Thanks Tim On 11/11/10 22:45, Howard Chu wrote: Tim Dyce wrote: Hi Howard, Thanks for the help :D We have been testing in ramdisk as well, to make sure that disk thrashing is not the root cause. If your searches are not running long enough to show up for profiling, increase the number of second level entries until you get something you can profile. Ah, there's a bug in your script, it's creating the 2nd-level entries with the wrong DN so the DB never had more than 250 entries. Now I've fixed that and run again and can see the behavior you're talking about. It's actually due to a particular design choice: Ordinarily at each level of the tree we keep an index tallying all of the children beneath that point. In back-bdb this index is used for subtree searches and for onelevel searches. (In back-hdb it's only used for onelevel.) However, as a write optimization, for the root entry of the DB, we don't bother to maintain this index, it's simply set to All entries. (Otherwise in the back-bdb case, there is far too much write overhead to maintain this index.) The problem is that All entries is actually a range 1 to N where N is the ID of the last entry in the DB. (And 1 is the ID of the root entry.) As you add entries, N keeps increasing, but 1 stays constant. When you do a subtree search, every entryID in the corresponding index slot is checked. In this case, with a subtree search starting at the root entry, you will always be iterating through every ID from 1 thru N, even though many of those IDs have been deleted, and it takes time for BDB to return no such object for all the deleted IDs. If you do all of your operations under a child entry instead of the database root entry, the performance will be constant. I've already verified this with a modified copy of your test. I can post it if you wish. Thanks Tim On 11/11/10 21:38, Howard Chu wrote: Tim Dyce wrote: Hi Dieter, Thanks for the tips on tuning, sadly the problem is still haunting us :( Andrey Kiryanov at CERN has been doing a lot of work on this performance degradation problem as well. He has tried BDB 4.8.30 and OpenLDAP 2.4.23 but the problem is still apparent. I've run the test setup you provided here http://www.openldap.org/lists/openldap-technical/201010/msg00237.html but so far I'm seeing constant (0:00.0 second) results from ldapsearch. Some differences - I used back-hdb, which is going to be superior for a heavy add/delete workload. Also my test DB is running on a tmpfs (RAMdisk). The basic test we are running (sent earlier) creates 100 ou entries in the root, each with 250 child ou entries, then deletes 20-35% of these and re-adds them. For each deletion cycle the ldapsearch performance degrades, taking longer to complete the search each time. The performance is consistent, across restarts of slapd, and tied to the current state of the database. I have tried rsyncing out the database, and returning it later, and the performance is consistent with the number of deletion cycles the database has undergone. The only clue I have is that when dumping the databases which db_dump it's clear that the ordering of the database becomes increasingly less aligned with the order of the output data when doing a full tree search as we are. Which suggests that the database is writing frequently accessed entires too often instead of holding them in cache? I have run cachegrind against the server at 2, 20 and 1000 deletion iterations and the results are very different - http://www.ph.unimelb.edu.au/~tjdyce/callgrind.tar.gz The number of fetches grows massively over time. Anything you guys can suggest would be much appreciated, it's started to affect quite a number of our grid sites. Cheers, Tim On 04/11/10 02:56, Dieter Kluenter wrote: Hi Dieter, I've done some more testing with openldap 2.3 and 2.4, on Redhat and Ubuntu. I even went as far as placing the BDB database directory in a ramdisk. But the performance still seems to degrade over time as data is added then deleted repeatedly from the ldap server. It looks like the BDB database starts to fragment or lose structure over time? I've tried a few DB options that seem to have some impact. Any ideas on what I can do from here? Quite frankly, I have no clue, all i can do is guessing. First let's define the problem: you have measured the presentation of search Results the client side, and you observered an increase of time required to present the results. Mostlikely it is either
Re: Asynchronicity
Shankar Anand R wrote: On Mon, Nov 8, 2010 at 5:57 PM, Howard Chu h...@symas.com mailto:h...@symas.com wrote: Shankar Anand R wrote: Hi, Is there any workaround way by which we will be able to do a DIGEST-MD5 - SASL LDAP bind asynchronously? Howard: Is there a plan to have an asynchronous ldap_sasl_interactive_bind in the near future? Any time lines for that? No future plan. It's in CVS as of October 13, so it's already in the past. Great! Thanks for the information. I understand that the openldap project does not follow strict release dates. But I see that there is an average of 3 months between 2.4.x and 2.4.x+1. Can you help me by giving an approximate date when 2.4.24 will be released (with this fix)? No idea. You can help by actually using/testing the code and giving feedback on how it worked out for you. If it still has problems, then it cannot be released sooner. If no one is actually going to use it, then it will not be released. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Chaining not working
Jaap Winius wrote: Hi folks, While testing the current Debian squeeze version of OpenLDAP, v2.4.23-6, in a provider/consumer syncprov/syncrepl (refreshAndPersist) configuration, using a patch(1) written by Pierangelo, I have not been able to get chaining to work. The consumer, ldaps2, was configured with a referral(2) to the provider, ldaps1, as well as a chaining configuration(3). A couple of authzTo rules(4) were added to its entry in the DIT, which immediately replicated to the consumer, and the provider was configured with an olcAuthzPolicy directive for to(5). So far, so good. However, when using ldapmodify on the consumer to test that an entry in the DIT could actually be modified (the description attr of the consumer's entry) from there as a result, I got this response: modifying entry cn=ldaps2,dc=example,dc=com ldap_modify: Referral (10) referrals: ldap://ldaps.example.com/cn=ldaps2,dc=example,dc=com I know ldapmodify doesn't understand referrals; this is where chaining should have worked instead. So, I removed the referral from the consumer's configuration to see what would then happen with the same command: modifying entry cn=ldaps2,dc=example,dc=com ldap_modify: Server is unwilling to perform (53) additional info: shadow context; no update referral (shadow context?). In both cases, this shows up in the syslog as a result: Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 ACCEPT from IP=127.0.1.1:43982 (IP=0.0.0.0:389) Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn=cn=admin,dc=example,dc=com method=128 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 BIND dn=cn=admin,dc=example,dc=com mech=SIMPLE ssf=0 Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=0 RESULT tag=97 err=0 text= Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD dn=cn=ldaps2,dc=example,dc=com Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 MOD attr=description Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=1 RESULT tag=103 err=53 text=shadow context; no update referral Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 op=2 UNBIND Nov 12 00:48:54 ldaps2 slapd[23862]: conn=1002 fd=19 closed Have I made a mistake somewhere, or could this be another bug? The chain overlay needs to be configured on the frontendDB in order to catch these update referrals. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: How to convert Solaris m5 passwords to LDAP?
Christian Schmidt wrote:
Hello Howard,
thank you very much for your reply.
Howard Chu, 10.11.2010 (d.m.y):
No conversion is necessary, as long as you built OpenLDAP with
--enable-crypt and you're using the native C library's crypt() (and
not e.g. OpenSSL's crypt())
I just gave this a try and changed a user's password to password
which resulted in the MD5 hash
$md5$4bNuD9JW$$P/Lr2qkcw9wv1yYNokfQG0.
I created an LDIF file with the following line and imported it into
the directory:
userPassword: {CRYPT}$md5$4bNuD9JW$$P/Lr2qkcw9wv1yYNokfQG0
The phrase after {CRYPT}) is the hash Solaris put in its /etc/shadow.
After importing this line into the LDAP directory, I could *not* login
as the corresponding user using the password password. :-(
(And the slapd is actually running on Solaris.)
It is not: We're running OpenLDAP on Debian GNU/Linux...
Then you have no chance. Notice I said and in all of those conditions above.
Since you have not met all of the conditions, this cannot work.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Performance issues lately.
Jorgen Lundman wrote: Now repeat the db_stat call and see how long it takes the 2nd time. It does indeed speed up, if I do not wait too long between tests. real1m27.712s real0m29.696s real0m4.332s real0m4.452s If it slows down after you wait a while, that means some other process on the machine is using the system RAM and forcing the BDB data out of the system cache. Find out what other program is hogging the memory, it's obvious that BDB is not doing anything wrong on its own. 4 seconds is much nicer. So what you are saying is that BDB uses mmap, and operations inside this memory will trigger reads inside the kernel which do not show as libc syscalls. Rats. So it may be IO? I need to throw even more memory at it, and live with the increasing startup times? How does the set_cachesize relate to the mmap usage? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: self signed certificate
Dieter Klünter wrote: Fri, Nov 19, 2010 at 02:58:30PM -0200, Márcio Luciano Donada wrote: Hi list, When using TLS, I have information that I'm using a self-signed certificate, as shown below: # ldapsearch -x -d5 -b 'ou=Usuarios,dc=xx,dc=com,dc=br' -H ldaps://121.1.1.97/ '(objectclass=*)' ldap_url_parse_ext(ldaps://121.1.1.97/) ldap_create ldap_url_parse_ext(ldaps://121.1.1.97:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP 121.1.1.97:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 121.1.1.97:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 TLS trace: SSL_connect:before/connect initialization TLS trace: SSL_connect:SSLv2/v3 write client hello A TLS trace: SSL_connect:SSLv3 read server hello A TLS certificate verification: depth: 0, err: 18, subject: /C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=ldap.xx.com.br, issuer: -State/O=Internet Widgits Pty Ltd/CN=ldap.xx.com.br TLS certificate verification: Error, self signed certificate TLS trace: SSL3 alert write:fatal:unknown CA TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS trace: SSL_connect:error in SSLv3 read server certificate B TLS: can't connect: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (self signed certificate). ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) OpenLDAP is quite picky about correct certificate chains. No, the software will accept whatever you tell it to use, if you configure it appropriately. You really should create a full certificate chain, that is, a ca, a server certificate and a server key. But yes, the Project always recommends that you do the right thing. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Content-Based Access Control?
Frank Rust wrote: Hi all, would it be possible to configure a content-based access control? Yes. Read the slapd.access(5) manpage. I have following configuration: my ldap contains user data. Some of the users are local ones and have a regular password entry. They shall be able to change their password. Other users are remotely authenticated with saslauthd. They shall not be able to change their 'password' which is just a redirection. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: Want interesting restrictions to ldap auth on different servers to different users
c0re wrote: 2010/11/19 Phuong Marie VUONGmangocph...@gmail.com: Hello, First, im sorry about my English. I share here my experience which worked for limit acces host/group of host for user... In the configuration of ldap client /etc/ldap.conf , i have activate the host attribute and a filter in nss_base_passwd pam_check_host_attr yes nss_base_passwd ou=People,dc=x,dc=?one?|(host=hostname.domain)(host=PatternofHostGroup)(host=*) In the user entry, add the host attribute And in the host set, you can put the pattern value correpond of the level that you want to authorize to connect , for exe : hostname.domain or PatternofHostGroup or * Hope that can help 2010/11/19 c0renr1c...@gmail.com can you give an example of usage pam_check_host_attr? And how can I use group of hosts and assign user to this group to permit access user to this group avoiding enumerating hosts in users dn each time I add new user? What should I set in host:? Hostname of server? How host attr are sent to pam_ldap? 2010/11/18 Aaron Richtonrich...@nbcs.rutgers.edu: On Thu, 18 Nov 2010, c0re wrote: I mean user user1 can must login only on server1,server2 and server3. And user2 can login only on server5 and server2. You could probably overload almost anything (dyngroups, OpenLDAP ACLs, search filters, who knows) to accomplish this, but the cleanest way to do this in pam_ldap would utilize pam_check_host_attr. I assume pam_ldap because you mentioned pam_groupdn which is not an OpenLDAP configuration directive. -- MilanPhuong 06.17.34.09.77 09.53.57.04.94 http://www.phuong.fr/photos/ I moved a bit different way. I used pam_groupdn in ldap.conf and created a group for each server. Now if I add user to ldap, I need to add to groups memberUid: `userdn`. And user will be able to login to those servers in which groups is user as a member. But if I got 100-200 servers and want to give access to new user to all this servers, I should add user to all groups. Of course it's a waste of time and it's possible to be done via some external shell/perl script, but may be there another way in openldap? pam_check_host_attr do almost same. If I add user - I need to add all hosts to user attr host:. So it's same work I think. Read up on the nssov overlay. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Re: OpenLDAP runs OK, Mac Mail and Address book do not display entries.
Ask on an Apple forum. Toomas Vendelin wrote: Hi, I have set up an OpenLDAP server on a CentOS 5.5 machine and uploaded test data from ldif file. Apache directory studio connects to server nicely from my Mac and displays the records. Apple Mail and address book also seem to connect OK, but no search results returned in Address Book, and e-mails are not auto-completed in Mail. At the same time, I successfully connect to other publicly accessible servers, so it is probably a fault in my LDIF data. What is it? Do I need to use some schema specific to Apple? As for now, only the default ones are used. My LDIF data (all characters are fictional): Code: dn: dc=minu,dc=biz dc: minu objectClass: dcObject objectClass: organization o: Vendelin Barilko dn: ou=people,dc=minu,dc=biz ou: people objectClass: organizationalUnit dn: cn=Deniska Borilko, ou=people,dc=minu,dc=biz cn: Deniska Borilko objectClass: inetOrgPerson sn: Borilko mail: de...@somedomain.com My LDAP settings both in Mail and address book: Code: Search base: ou=people,dc=minu,dc=biz Scope: subtree Thanks in advance! Toomas -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
