openldap-technical December 2014

openldap-technical@openldap.org

44 participants
55 discussions

Re: Antw: adding a custom attribute
by Michael Ströder 10 Dec '14

10 Dec '14

Ulrich Windl wrote: >>>> http://tools.ietf.org/html/rfc4512#section-2.5 >>> >>> I couldn't quite read it from there: The closest match I found was: "oid = >>> descr / numericoid", but I was talking about the "on wire" protocol of LDAP. >>> Are there really named objects and attributes? >> >> You really ask to be spoon-fed. >> [..] >> Is it really so hard for you to find the line >> "Examples of valid attribute descriptions:" >> in this particular section? > > No, but what exactly does the example tell about the on-wire protocol? http://tools.ietf.org/html/rfc4511#section-4.1.4 Ciao, Michael.

1 0

Re: Antw: adding a custom attribute
by Michael Ströder 10 Dec '14

10 Dec '14

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb am 10.12.2014: >>> I thought the LDAP _protocol_ uses OIDs everywhere, and names are just for >>> human users...? >> >> Nope. One could regard this as design deficiency (in comparison to X.500). >> >> http://tools.ietf.org/html/rfc4512#section-2.5 > > I couldn't quite read it from there: The closest match I found was: "oid = > descr / numericoid", but I was talking about the "on wire" protocol of LDAP. > Are there really named objects and attributes? You really ask to be spoon-fed. Aren't you the one who claimed to write schema-aware LDAP client. If yes, then you should really know RFC 4512 by heart. Is it really so hard for you to find the line "Examples of valid attribute descriptions:" in this particular section? Ciao, Michael. P.S.: You're one nonsense posting away from my killfile.

1 0

Re: Antw: RE: N-Way multimaster Replication with TLS and multiple server certificates
by Michael Ströder 10 Dec '14

10 Dec '14

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb am 10.12.2014 um 09:44 in > Nachricht <548807E4.5000108(a)stroeder.com>: >> Ulrich Windl wrote: >>>> I use a cert with the VIP used by clients, and the hostnames used between >>>> the servers all setup in the subjectaltname of the certificate. >>> >>> But this "solution" does not scale well when adding or removing servers... >> >> Why does it not scale? >> >> If you have an individual cert for each server with the VIP DNS name in >> subjectAltName you can just add servers as needed. > > The point is: If you change one server, you'll have to update certificates for > all active servers; Nonsense. This will only be the case if you change the VIP's DNS name. Or could you please tell us what's so hard to understand with "individual cert for each server"? > not to talk about that fact that all certificates will > expire exactly at the same time. Uuuh... yes, there's work out there to be done. So what's the real problem? Ciao, Michael.

1 0

Re: Antw: Performance impact of linking libwrap
by Michael Ströder 10 Dec '14

10 Dec '14

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb am 10.12.2014 um 09:46 in > Nachricht <54880865.3060404(a)stroeder.com>: >> Ulrich Windl wrote: >>> As you are building anyway, why not do a simple performance test as part > of >>> your package testing? >> >> Why don't *you* conduct a performance test and report here? > > Have one query. Run it (e.g. ldapsearch) 1000 times (or more if it's too fast) > against the server; with and without libwrap (maybe also with and without > access denied). I'm sure you don't need my help for this ;-) Surely it's not a matter of lacking skills. It's easier to request something from others who are already spending their spare time doing voluntary unpaid work than to actually do the work yourself. So ask yourself: Where are *your* contributions. Ciao, Michael.

1 0

N-Way multimaster Replication with TLS and multiple server certificates
by coma 10 Dec '14

10 Dec '14

Dear List, i'm using N-Way multimaster replication with 2 servers (i will use it on 30 servers soon). Each server is using it's own certificate, so the content of TLSCertificateFile and TLSCertificateKeyFile is different in the cn=config of each of them. My problem is that cn=config is replicated on all servers, including TLSCertificateFile and TLSCertificateKeyFile... therefore the replication obviously not working (the certificate and key path of the first server are replicated on the second server). I know there is some solutions to workaround this "issue", like: - Don't replicate cn=config - Use the same certificate and key for all servers - Use the same certificate and key path in cn=config (ex: /etc/openldap/cert/common_cert_name.pem and /etc/openldap/cert/common_cert_name.key) and then make symlinks to the correct files on the local server but I would avoid this type of solutions if possible, so i would like to know if there is a solution to avoid to replicate TLSCertificateFile and TLSCertificateKeyFile, or other trick? Thank you in advance for any response, Best regards,

5 6

Q: roles for authentication
by Ulrich Windl 10 Dec '14

10 Dec '14

Hi! I have a question: You can define roles for authentication this way: Multiple DNs can be members of a group/rolem, and you can use group names when assigning ACLs. To authenticate, a user will use his DN and own password. Now when a DN is member of multiple roles/groups, authenticating as member assignes all the rights each group/role has. The idea of a role however is that a user "changes hats", depending on the task he is doing. I wonder: Is it possibe to authenticate with a group/role's DN and the user's (a memeber) password? Or is there some other mechanism to accieve what I want? Regards, Ulrich

2 3

Re: Antw: Re: Q: LDIF: use replace instead of add/delete?
by Howard Chu 09 Dec '14

09 Dec '14

Ulrich Windl wrote: >>>> Howard Chu <hyc(a)symas.com> schrieb am 09.12.2014 um 16:24 in Nachricht > <5487144B.8010703(a)symas.com>: >> Ulrich Windl wrote: >>> Hello! >>> >>> I have a question: >>> Is it always OK to use LDIF "replace", even if the attribute doesn't >> exist yet? If so, is it also OK to use "replace" with out specifying an >> attribute value instead of using "delete"? >>> I actually managed to do the first one, and the operation is logged >>> as >> "replace" not as "add" in accesslog. I wrote a program that uses >> accesslog to create an "undo-LDIF" to undo recent changes on demand. Now >> with that "replace" having succeeded, the undo operation created for it >> would be the second case ("replace" with no new value). >> >> Read RFC4511 section 4.6. >> >> General questions about how LDAP works don't belong here. Use the >> ldap(a)umich.edu mailing list. > > Of course I meant "does it work with openLDAP" when asking "does it > work in LDAP". If you meant "in OpenLDAP" than that's what you should have written. Since you asked about "LDAP" you got the correct answer to your question. Meanwhile, your question still is about the basic semantics of a Modify/Replace operation. The semantics of this operation are defined in the LDAP RFC I pointed you to. Every server that claims to support LDAPv3 is required to implement these semantics. Naturally, since OpenLDAP has been the reference implementation of LDAP for nearly 2 decades, of course it implements this aspect of the spec. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: Antw: adding a custom attribute
by Michael Ströder 09 Dec '14

09 Dec '14

Ulrich Windl wrote: >>>> Michael Ströder <michael(a)stroeder.com> schrieb am 09.12.2014 um 16:31 in > Nachricht <548715BF.7050800(a)stroeder.com>: >> Ulrich Windl wrote: >>> I thought a schema having a OID is the same everywhere; would a modified >> schema need a new OID then? >> >> Best practice is to assign a new OID if anything changes for a schema >> element. >> >> 99.9999% of LDAP client applications don't care about OIDs though. > > I thought the LDAP _protocol_ uses OIDs everywhere, and names are just for > human users...? Nope. One could regard this as design deficiency (in comparison to X.500). http://tools.ietf.org/html/rfc4512#section-2.5 Ciao, Michael.

1 0

is syncrepl + lmdb possible ?
by Andrew G 09 Dec '14

09 Dec '14

I'm wanting to implement an N-way multimaster with lmdb, but it seems that syncrepl is whinging about the db not being supported ? Perhaps I need a different/later version of syncprov ? I cant seem to find a definitive answer to this. redhat -> openldap-servers-2.4.23-32.el6_4.1.x86_64 -- Andrew Gray Professional Unix Administration. Vizzini <http://www.imdb.com/name/nm0001728/?ref_=tt_trv_qu>: Wait till I get going! Now, where was I? Man in Black <http://www.imdb.com/name/nm0000144/?ref_=tt_trv_qu>: Australia.

3 3

Re: N-Way multimaster Replication with TLS and multiple server certificates
by coma 09 Dec '14

09 Dec '14

Hello, Thanks for your prompt reply. Yes i'm using also the CA path attribute to specify my CA trust chain. So has you said, i will use the same path on each nodes. Thanks again! 2014-12-09 20:30 GMT+01:00 Quanah Gibson-Mount <quanah(a)zimbra.com>: > --On Tuesday, December 09, 2014 7:14 PM +0100 coma <coma.inf(a)gmail.com> > wrote: > > >> Dear List, >> >> i'm using N-Way multimaster replication with 2 servers (i will use it on >> 30 servers soon). Each server is using it's own certificate, so the >> content of TLSCertificateFile and TLSCertificateKeyFile is different in >> the cn=config of each of them. >> >> My problem is that cn=config is replicated on all servers, including >> TLSCertificateFile and TLSCertificateKeyFile... therefore the replication >> obviously not working (the certificate and key path of the first server >> are replicated on the second server). >> >> I know there is some solutions to workaround this "issue", like: >> - Don't replicate cn=config >> - Use the same certificate and key for all servers >> - Use the same certificate and key path in cn=config (ex: >> /etc/openldap/cert/common_cert_name.pem and >> /etc/openldap/cert/common_cert_name.key) and then make symlinks to the >> correct files on the local server >> >> but I would avoid this type of solutions if possible, so i would like to >> know if there is a solution to avoid to replicate TLSCertificateFile and >> TLSCertificateKeyFile, or other trick? >> > > Every server must be able to validate the cert of the other MMR nodes. > For that, it would be easiest to use the CA path attribute (vs file > attribute). For the cert setup for the servers themselves, generally yes, > you can work around that by having the same path to the cert on each node. > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical December 2014