Re: Antw: adding a custom attribute
by Michael Ströder
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.
8 years, 9 months
Re: Antw: adding a custom attribute
by Michael Ströder
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.
8 years, 9 months
Re: Antw: RE: N-Way multimaster Replication with TLS and multiple server certificates
by Michael Ströder
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.
8 years, 9 months
Re: Antw: Performance impact of linking libwrap
by Michael Ströder
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.
8 years, 9 months
N-Way multimaster Replication with TLS and multiple server certificates
by coma
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,
8 years, 9 months
Q: roles for authentication
by Ulrich Windl
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
8 years, 9 months
Re: Antw: Re: Q: LDIF: use replace instead of add/delete?
by Howard Chu
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/
8 years, 9 months
Re: Antw: adding a custom attribute
by Michael Ströder
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.
8 years, 9 months
Re: N-Way multimaster Replication with TLS and multiple server certificates
by coma
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
>
8 years, 9 months
