http://permalink.gmane.org/gmane.comp.ldap.umich hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.ldap.umich/3630 <pre>HI! Is there any known LDAP extended control which is used more than once in a LDAPRequest or LDAPResponse? Or can a client expect that a controlType is only used exactly once in the list of returned controls in a single message? Up to now I've never seen something like this but one never knows. Ciao, Michael. </pre> Michael Ströder 2012-04-12T09:23:10 http://permalink.gmane.org/gmane.comp.ldap.umich/3629 <pre>Hi All and especially thanks to Linus. I reconfirmed the credentials and found that the account had not been correctly configured. So I have it working. Issues were: 1. Certificate wasn't correctly permissioned to allow it to validate itself (it was self signed and we needed "purpose" of signing set to YES) 2. the credentials given to me were wrong. Thanks to everyone! Peter </pre> Peter Hawkins 2012-04-04T01:39:14 http://permalink.gmane.org/gmane.comp.ldap.umich/3628 <pre>Hey Peter, On Mon, Apr 2, 2012 at 6:18 AM, Peter Hawkins &lt;phawkins-muWJ0Y1xjZnvnOemgxGiVw&lt; at &gt;public.gmane.org&gt;wrote: And did you verify your credentials and your account on a windows machine/ some active directory admin interface within that active directory yet? As certificate trust verification seems to work, your credentials (bindDn, password) may still be simply wrong or the account may not be allowed to authenticate. What version of Windows Server is that Active Directory running on? Regards, Linus </pre> Linus van Geuns 2012-04-03T20:58:25 http://permalink.gmane.org/gmane.comp.ldap.umich/3627 <pre>Hi All Well I have now received back two new certificates - One for the CA and one for the server and have got further. I have the following in my config: #REFERRALS off TLS_REQCERT demand TLS_CACERT /usr/local/etc/openldap/certs/CACert.pem TLS_CERT /usr/local/etc/openldap/certs/eLearningCert.pem -------------------------------------------------------------------------------------------------------- The client certificate has the following settings: # openssl x509 -noout -subject -issuer -startdate -enddate -purpose -in eLearningCert.pem subject= /C=AU/ST=NSW/O=Client Name/OU=ADLDS/CN=hostname.xx.yy.zz issuer= /C=AU/ST=NSW/O=Client Name/OU=ADLDS/CN=hostname.xx.yy.zz notBefore=Mar 30 03:36:03 2012 GMT notAfter=Mar 29 03:36:03 2017 GMT Certificate purposes: SSL client : Yes SSL client CA : No SSL server : Yes SSL server CA : No Netscape SSL server : Yes Netscape SSL server CA : No S/MIME signing : Yes S/MIME signing CA : No S/MIME encryption : Yes S/MIME encryption CA : No CRL signing : Yes CRL signing </pre> Peter Hawkins 2012-04-02T04:18:34 http://permalink.gmane.org/gmane.comp.ldap.umich/3626 <pre>Hey Peter and Quanah, On Thu, Mar 8, 2012 at 7:36 PM, Quanah Gibson-Mount &lt;quanah-zAQalKWTt5vQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt;wrote: Yeah, that identity vs. account thing is a somewhat rare insight, especially when it comes to applications that need more than just account or identity data from directories. If you do seperate them, you will almost certainly require some feature to build virtual objects/views containing data from both, accounts and the corresponing identity. Using persistent identifiers in RDNs for identities as well as accounts can simplify many use cases. Whether it is worth the effort is something that you must decide for yourself based on the complexity of the required migration an what applications/services would be affected. Regards, Linus </pre> Linus van Geuns 2012-03-09T11:44:48 http://permalink.gmane.org/gmane.comp.ldap.umich/3625 <pre>Hey Peter, On Fri, Mar 9, 2012 at 6:11 AM, Peter Hawkins &lt;phawkins-muWJ0Y1xjZnvnOemgxGiVw&lt; at &gt;public.gmane.org&gt;wrote: Seems like it. I'd guess, those AD administrators wont want to exchange their certificate? While we certainly could start a discussion on how reasonable it is to require a self-signed certificate to have a "Certificate Signing" extension set, you might have two workarounds: A) Tell OpenSSL to "trust" that self-signed certificate is a CA. - I dont know, whether that is possible. B) Disable the purpose check for CA certificates whithin the context of your LDAP client. - I dont know, whether that is possible, either. If I remember correctly, your gnutls package verified the self-signed certificate. So, linking your LDAP client with gnutls instead of openssl might be an option, too. Regards, Linus </pre> Linus van Geuns 2012-03-09T11:24:18 http://permalink.gmane.org/gmane.comp.ldap.umich/3624 <pre>Hi Linus Thanks for sticking with me on this... OK I did that and directed each to a file. Diff says the files are identical. I also now have some information from the client about the DN, but I'm starting to learn a bit from reading forums. Meanwhile I tried this: # openssl verify -verbose -issuer_checks /usr/local/etc/openldap/certs/eLearningPublic.pem /usr/local/etc/openldap/certs/eLearningPublic.pem: /CN=mldshomdsp01.ce.xyz.com.au error 32 at 0 depth lookup:key usage does not include certificate signing /CN=mldshomdsp01.ce.xyz.com.au error 32 at 0 depth lookup:key usage does not include certificate signing /CN=mldshomdsp01.ce.xyz.com.au error 32 at 0 depth lookup:key usage does not include certificate signing /CN=mldshomdsp01.ce.xyz.com.au error 32 at 0 depth lookup:key usage does not include certificate signing /CN=mldshomdsp01.ce.xyz.com.au error 20 at 0 depth lookup:unable to get local issuer certificate When I googled that error I found that it looks like openldap doesn't like the certificat</pre> Peter Hawkins 2012-03-09T05:11:26 http://permalink.gmane.org/gmane.comp.ldap.umich/3623 <pre>--On Thursday, March 08, 2012 3:07 PM +0100 Peter Schober &lt;peter.schober-4JhlDu4IDl0juwv8T7myQQ&lt; at &gt;public.gmane.org&gt; wrote: It creates: suregid=&lt;whatever&gt;,cn=people,dc=stanford,dc=edu For people. For accounts, it uses uid uid=joe,cn=accounts,dc=stanford,dc=edu People are not accounts. ;) --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration </pre> Quanah Gibson-Mount 2012-03-08T18:36:34 http://permalink.gmane.org/gmane.comp.ldap.umich/3622 <pre>* Quanah Gibson-Mount &lt;quanah-zAQalKWTt5vQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; [2012-03-07 18:04]: Well, I can see[1] that it's a registry identifier that's unique per person and that accounts refer to it via the owner attribute. I did not however find how DNS (and most-specific RDNs) are constructed, but take your above answer to mean that Standford creates DNs as suRegID=$whatever,cn=accounts,$BASEDN OK, thanks, -peter [1] by searching around in https://itservices.stanford.edu/service/directory/datadefs/people and related pages </pre> Peter Schober 2012-03-08T14:07:55 http://permalink.gmane.org/gmane.comp.ldap.umich/3621 <pre>Hey Peter, On Wed, Mar 7, 2012 at 2:13 AM, Peter Hawkins &lt;phawkins-muWJ0Y1xjZnvnOemgxGiVw&lt; at &gt;public.gmane.org&gt;wrote: connecting with s_client to port 636? openssl s_client -connect ${hostname_or_ip}:636 -CAfile /usr/local/etc/openldap/certs/eLearningPublic.pem Somewhere in the output of s_client, you will find: -8&lt;---------------- [..] Server certificate -----BEGIN CERTIFICATE----- [..] -----END CERTIFICATE----- [..] -8&lt;---------------- Copy the certificate starting with the "-----BEGIN CERTIFICATE-----" line and eding with (including) the "-----END CERTIFICATE-----" into a file, e.g. "activedir.pem". After that, do openssl x509 -noout -text -in activedir.pem and compare that to your "eLearningPublic.pem". If it differs from your "eLearning.pem", you should check whether the server provided certificate is self-signed or a CA chain is required. The certificate used with StartTLS MAY be different from that used for LDAPS, but I would not expect that from an Active Directory. Also, you SHOULD check in with</pre> Linus van Geuns 2012-03-07T19:15:57 http://permalink.gmane.org/gmane.comp.ldap.umich/3620 <pre> My apologies for writing to the wrong list. I set up replication with that filter and it is working as wanted. The superior entries exist already and should not be deleted of course. Yes, it's a single-master environment. Provider and consumer have partly different data for non-replicated entries there. Because provider and consumer are installed on different hosts and some entries are based on the local hostname there. From a quick look into that it may be a solution for me. Thank you, Michael! Sorry again for having sent the original question here. Kind regards, Michael </pre> Wuensche Michael 2012-03-07T18:53:59 http://permalink.gmane.org/gmane.comp.ldap.umich/3619 <pre> Technical questions specific for OpenLDAP should be directed to the openldap-technical mailing list (see http://www.openldap.org/lists/). This is possible by setting a filter in your syncrepl-statement. But you have to take care whether superior entries of replicated entries are also covered by your filter. It seems you're writing to the consumer in a single-master environment where the consumer is read-only. Why not simply write to the provider? Why do you want that? Maybe you want to use something like slapo-translucent(5). Ciao, Michael. </pre> Michael Ströder 2012-03-07T18:40:07 http://permalink.gmane.org/gmane.comp.ldap.umich/3618 <pre>--On Wednesday, March 07, 2012 6:32 PM +0000 Wuensche Michael &lt;Michael.Wuensche-aZ+A4iwyWidWk0Htik3J/w&lt; at &gt;public.gmane.org&gt; wrote: Questions about OpenLDAP should be sent to openldap-technical-NMOUhb4S1gZg9hUCZPvPmw&lt; at &gt;public.gmane.org This list is for general, non-implementation specific, questions about LDAP. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration </pre> Quanah Gibson-Mount 2012-03-07T18:37:49 http://permalink.gmane.org/gmane.comp.ldap.umich/3617 <pre>I have an Openldap environment with 2 servers, one serving as provider for 2 databases and one as consumer. On one of the databases I only want to replicate certain entries, filtered by objectclass. I use syncrepl for replication. Now I would like to write entries, which are not covered by the filter and so are not replicated. But Openldap sends me a referral to the master on write attempts if I use the updateref directive. If I don't use this directive, I get error 53: unwilling to perform. Is there a way to have part of a databases entries to be replicated and others being allowed to write locally? Thanks a lot, Michael </pre> Wuensche Michael 2012-03-07T18:32:06 http://permalink.gmane.org/gmane.comp.ldap.umich/3616 <pre>Yes, I have seen some, but very little use of semantically void values. Generally what I have seen for companies that have gotten past the display name issue inherent in the MSFT tooling via provisioning automation and instead use userids or employeeids or some other value that is already set up with some generation system to guarantee uniqueness and used for tracking employees throughout the company. Several of the userid systems in use were specifically designed/built and have existed for years to avoid any need for renames since some systems don't handle renames well. Renames nor moves aren't generally much of a deal in the Active Directory world as the MSFT clients/apps mostly don't care. They dynamically look up the DNs via relatively static values to get to the objects that they need to deal with and dynamically discover the machines that provide the services they need. The issues generally crop up with non-MSFT based apps and systems using Active Directory that have hard coded values[1] instead of u</pre> joe 2012-03-07T17:52:25 http://permalink.gmane.org/gmane.comp.ldap.umich/3615 <pre>--On Wednesday, March 07, 2012 1:31 PM +0100 Peter Schober &lt;peter.schober-4JhlDu4IDl0juwv8T7myQQ&lt; at &gt;public.gmane.org&gt; wrote: See Stanford University's suRegID --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration </pre> Quanah Gibson-Mount 2012-03-07T17:03:52 http://permalink.gmane.org/gmane.comp.ldap.umich/3614 <pre>Digressing further from the original topic... * joe &lt;joe-VdL7z5lOYoXR7s880joybQ&lt; at &gt;public.gmane.org&gt; [2012-03-07 01:29]: In comparison with a person's real name using username (login name, NetID, whatever) as most specific RDN certainly is certainly preferrable. But I thought above moving away from using even the username for contruction of the RDN and instead create some semantically void, persistent, opaque identifier (think type 4 UUID or something like that, unknown to the user, so that's not something anyone would ever type into a login form for authN). I would hope to make object renames completely unnecessary (since usernames might still change -- by fiat -- how much we may try to avoid that) and also not give the username away when it's not needed, since it's currently always visible in the DN itself (or entryDN opattr). Is anyone doing that? Is it worth the effort? -peter </pre> Peter Schober 2012-03-07T12:31:54 http://permalink.gmane.org/gmane.comp.ldap.umich/3613 <pre> Sorry for the confusion. I used: TLS_CACERT /usr/local/etc/openldap/certs/eLearningPublic.pem </pre> Peter Hawkins 2012-03-07T01:13:36 http://permalink.gmane.org/gmane.comp.ldap.umich/3612 <pre>anonymous request like that (sorry for n00b question) Depends on the tools available to you. If you have a Windows machine, you can go to my website (www.joeware.net) and look for adfind.exe which is a command line ldap query tool designed with AD in mind. You would want to use a command like adfind -hh hostname -rootdseanon Also, if the LDAP port is open, you can try connecting via that with your ID and get the LDAPS stuff out of the way of the testing to validate you have a good ID. adfind -hh hostname -rootdse -u credential -up password -simple Probably not. The user ids usually aren't stored in the root of the ldap directory and there is no telling what they used for the RDN of the user object. Most companies, unfortunately, don't use username as the RDN value, they are usually using a display name of some sort (yes I know, stupid but is influenced by the default MSFT provisioning tools and Exchange). Overall I really think you need to contact the admins of the directory and ask them for some h</pre> joe 2012-03-07T00:28:09 http://permalink.gmane.org/gmane.comp.ldap.umich/3611 <pre>Hey, 2012/3/6 Michael Ströder &lt;michael-rG38yQ/2uf9Wk0Htik3J/w&lt; at &gt;public.gmane.org&gt; Well, as Michael already mentioned, the configuration option "require TLS for simple bind with password" will almost certainly implement a policy to reject any [simple] bind request that was not sent over LDAPS or LDAP with StartTLS. So, you must ensure that all applications connect to your eDirectory either via LDAPS or LDAP with StartTLS before implementing that policy. You should consult your directories' documentation for details on that configuration option. Regards, Linus </pre> Linus van Geuns 2012-03-06T20:16:14 http://permalink.gmane.org/gmane.comp.ldap.umich/3610 <pre> You said: "TLS...happens on the non-encrypted port...." TLS (and SSL) doesn't care what port it's on. It's just encryption. STARTTLS is a negotiation mechanism by which two hosts can agree to start a TLS session within a conversation on any port at all, but probably on the well-known port assigned to that protocol for unencrypted conversations and probably within a conversation that was not already encrypted (so far as the application layer knows). The port(s) to be used are standardized as part of the application protocol. I've seen lots of people get tied up in knots because they think that TLS has something to do with upward negotiation. It does not. TLS works just fine on port 636 for carrying an entire LDAP session encrypted. Upward negotiation is done by means not part of the encryption mechanism, such as STARTTLS or SASL (RFC4422 -- see section 3.7). You will not find "STARTTLS" anywhere in RFC5246 (The Transport Layer Security (TLS) Protocol Version 1.2). You will find it, among other plac</pre> Mark H. Wood 2012-03-06T15:46:26 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.ldap.umich