Hello everyone,
I launch "authconfig" within a script to setup my redhat6 boxes.
I noticed that authconfig does not set up sssd.conf properly : https://bugzilla.redhat.com/show_bug.cgi?id=874527
but the bug is declared as "closed" ?
First question :
could anyone confirm that authconfig does *not* configure sssd.conf with "--enablesss" and "--enablesssdauth" and that I therefore need to configure that file myself (by hand or within my script) ?
Second question:
I noticed that sssd seemed to work properly even without declaring the "ldap_uri" parameter within sssd.conf. Could anyone confirm that this parameter is not necessary and where does sssd collect the list of ldap servers to query in that case, ldap.conf ?
Thank you for any help,
Best regards,
--- Olivier
On Wed, Sep 25, 2013 at 11:42:15AM +0200, Olivier wrote:
Hello everyone,
I launch "authconfig" within a script to setup my redhat6 boxes.
I noticed that authconfig does not set up sssd.conf properly : https://bugzilla.redhat.com/show_bug.cgi?id=874527
but the bug is declared as "closed" ?
First question :
could anyone confirm that authconfig does *not* configure sssd.conf with "--enablesss" and "--enablesssdauth" and that I therefore need to configure that file myself (by hand or within my script) ?
The switches --enablesss and --enablesssdauth are meant for the case where the admin creates the sssd.conf manually and only wants the authconfig to setup the NSS and PAM stacks for him. So with the latest version, authconfig --enablesssdauth --enablesss should not touch the sssd.conf at all.
Second question:
I noticed that sssd seemed to work properly even without declaring the "ldap_uri" parameter within sssd.conf. Could anyone confirm that this parameter is not necessary and where does sssd collect the list of ldap servers to query in that case, ldap.conf ?
Yes, if the ldap_uri parameter is missing, then the SSSD falls back to DNS SRV discovery. As the sssd-ldap man page says:
""" ldap_uri, ldap_backup_uri (string): If neither option is specified, service discovery is enabled. """
Thank you Jakub,
if I may an additionnal question : would the sssd fallback mecanism work with the DNS discovery ?
Aka, if I'd configure this in the DNS :
_ldap._tcp.example.com. IN SRV 10 0 389 ldap1.example.com. _ldap._tcp.example.com. IN SRV 20 0 389 ldap2.example.com.
will sssd fallback properly to ldap2 if ldap1 does not respond ?
thanks,
--- Olivier
2013/9/25 Jakub Hrozek jhrozek@redhat.com
On Wed, Sep 25, 2013 at 11:42:15AM +0200, Olivier wrote:
Hello everyone,
I launch "authconfig" within a script to setup my redhat6 boxes.
I noticed that authconfig does not set up sssd.conf properly : https://bugzilla.redhat.com/show_bug.cgi?id=874527
but the bug is declared as "closed" ?
First question :
could anyone confirm that authconfig does *not* configure sssd.conf with "--enablesss" and "--enablesssdauth" and that I therefore need to configure that file myself (by hand or within my script) ?
The switches --enablesss and --enablesssdauth are meant for the case where the admin creates the sssd.conf manually and only wants the authconfig to setup the NSS and PAM stacks for him. So with the latest version, authconfig --enablesssdauth --enablesss should not touch the sssd.conf at all.
Second question:
I noticed that sssd seemed to work properly even without declaring the "ldap_uri" parameter within sssd.conf. Could anyone confirm that this parameter is not necessary and where does sssd collect the list of ldap servers to query in that case, ldap.conf ?
Yes, if the ldap_uri parameter is missing, then the SSSD falls back to DNS SRV discovery. As the sssd-ldap man page says:
""" ldap_uri, ldap_backup_uri (string): If neither option is specified, service discovery is enabled. """ _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/25/2013 09:06 AM, Olivier wrote:
Thank you Jakub,
if I may an additionnal question : would the sssd fallback mecanism work with the DNS discovery ?
Aka, if I'd configure this in the DNS :
_ldap._tcp.example.com http://tcp.example.com. IN SRV 10 0 389 ldap1.example.com http://ldap1.example.com. _ldap._tcp.example.com http://tcp.example.com. IN SRV 20 0 389 ldap2.example.com http://ldap2.example.com.
will sssd fallback properly to ldap2 if ldap1 does not respond ?
Yes, and in fact this is the recommended mechanism for setting up SSSD in your environment, since you need only to update the DNS records and all of your clients will have access to a new set of LDAP servers (i.e. if you provision additional ones and/or retire others).
Stephen Gallagher wrote:
On 09/25/2013 09:06 AM, Olivier wrote:
if I may an additionnal question : would the sssd fallback mecanism work with the DNS discovery ?
Aka, if I'd configure this in the DNS :
_ldap._tcp.example.com http://tcp.example.com. IN SRV 10 0 389 ldap1.example.com http://ldap1.example.com. _ldap._tcp.example.com http://tcp.example.com. IN SRV 20 0 389 ldap2.example.com http://ldap2.example.com.
will sssd fallback properly to ldap2 if ldap1 does not respond ?
Yes, and in fact this is the recommended mechanism for setting up SSSD in your environment, since you need only to update the DNS records and all of your clients will have access to a new set of LDAP servers (i.e. if you provision additional ones and/or retire others).
Hmm, I really wonder why SRV RRs are recommended over having a single service CNAME RR and maybe several A/AAAA RRs?
Especially I'm concerned whether the TLS hostname check is properley done in case of TLS connections (StartTLS ext.op or LDAPS). Because a hostname check has to be performed against *a-priori* knowledge of the client to fight against MITM attacks with DNS spoofing.
So if you're local configuration just knows "example.com" the server cert MUST have a subject alt name with that domain name. I doubt that LDAP clients really check this.
Ciao, Michael.
On Wed, Sep 25, 2013 at 08:22:57PM +0200, Michael Ströder wrote:
Hmm, I really wonder why SRV RRs are recommended over having a single service CNAME RR and maybe several A/AAAA RRs?
In my opinion, the biggest advantages are centrally defined failover using the "priority field" and the ability to evenly distribute load using "weight".
Jakub Hrozek wrote:
On Wed, Sep 25, 2013 at 08:22:57PM +0200, Michael Ströder wrote:
Hmm, I really wonder why SRV RRs are recommended over having a single service CNAME RR and maybe several A/AAAA RRs?
In my opinion, the biggest advantages are centrally defined failover using the "priority field" and the ability to evenly distribute load using "weight".
But really distributing the load would require adjusting the weight dynamically, wouldn't it?
Ciao, Michael.
On Wed, Sep 25, 2013 at 09:00:42PM +0200, Michael Ströder wrote:
Jakub Hrozek wrote:
On Wed, Sep 25, 2013 at 08:22:57PM +0200, Michael Ströder wrote:
Hmm, I really wonder why SRV RRs are recommended over having a single service CNAME RR and maybe several A/AAAA RRs?
In my opinion, the biggest advantages are centrally defined failover using the "priority field" and the ability to evenly distribute load using "weight".
But really distributing the load would require adjusting the weight dynamically, wouldn't it?
Right, the SRV syntax merely allows you to say "direct 40% of traffic to box A, 40% to box B and 20% to box C. If neither of them is available, go to box D"
Hello Jakub and all,
may be the following could help : to be honnest, from an operational point of view I like the centralisation perspective offered by DNS discovery.
Any comment on these test/audit are welcomed.
for the following audit, the client side is rhel6-web.prod-int.example.fr: 10.yy.yy.17
Let see what says the dns about ldap service :
# dig _ldap._tcp.example.fr SRV
;; QUESTION SECTION: ;_ldap._tcp.example.fr. IN SRV
;; ANSWER SECTION: _ldap._tcp.example.fr. 172800 IN SRV 10 0 389 ldap3.location1.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 20 0 389 ldap1.location2.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 30 0 389 ldap2.location3.example.fr.
;; AUTHORITY SECTION: ...
;; ADDITIONAL SECTION: ldap3.example.fr. 172800 IN A 10.xx.xx.3 ldap1.example.fr. 172800 IN A 10.xx.xx.1 ldap2.example.fr. 172800 IN A 10.xx.xx.2
Now let's restart sssd:
# tshark -i eth1 not port 22
34.525938 10.xx.xx.17 -> 10.xx.xx.3 TLSv1 Application Data 34.525969 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Encrypted Alert 34.525982 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [FIN, ACK] Seq=1691 Ack=3075 Win=23296 Len=0 TSV=746424 TSER=60539402 34.526883 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36915 [FIN, ACK] Seq=3075 Ack=1692 Win=22016 Len=0 TSV=60551396 TSER=746424 34.526897 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [ACK] Seq=1692 Ack=3076 Win=23296 Len=0 TSV=746425 TSER=60551396 34.562795 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A rhel6-web.prod-int.example.fr 34.563250 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.yy.yy.17 35.568646 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query SRV _ldap._ tcp.example.fr
-->> HERE:
35.569170 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response SRV 20 0 389 ldap1.example.fr SRV 30 0 389 ldap2.example.fr SRV 10 0 389 ldap\ 3.example.fr 35.569421 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A ldap3.example.fr 35.569625 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.xx.xx.3 35.569774 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=747468 TSER=0 WS=6 35.570242 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 TSV=60552439 TSER=747468 WS=7 35.570257 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSV=747468 TSER=60552439 35.570594 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 35.570786 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [ACK] Seq=1 Ack=32 Win=14592 Len=0 TSV=60552440 TSER=747469 35.570987 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 35.570994 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=747469 TSER=60552440
-->> HERE:
35.578964 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 35.579506 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 35.579513 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 35.579537 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=747478 TSER=60552448 35.581211 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 35.581994 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec, Encrypted Handshake Message
--> sound's OK !
now let's have a look if I log in from civette.example.fr (10.zz.zz.94) :
# tshark -i eth1 not port 22 0.000000 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query PTR 94.zz.zz.10.in-addr.arpa 0.000306 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response PTR civette.example.fr 0.000507 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A civette.example.fr 0.000703 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.zz.zz.94 0.007700 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [PSH, ACK] Seq=1 Ack=1 Win=364 Len=565 TSV=845893 TSER=60553254 0.008561 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [PSH, ACK] Seq=1 Ack=566 Win=173 Len=53 TSV=60650865 TSER=845893 .... 4.674892 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSV=850561 TSER=60655531
-->> HERE :
4.675045 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 4.675213 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36918 [ACK] Seq=1 Ack=32 Win=14592 Len=0 TSV=60655531 TSER=850561 4.675473 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 4.675479 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=850561 TSER=60655532 4.675677 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 4.676129 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 4.676136 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 4.676176 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=850562 TSER=60655532 4.677304 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 4.678041 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec, Encrypted Handshake Message
....
--> to be honest I don't read fluently all this, but as far as I can see, it sounds to work very well (and I log in properly)
From a configuration point of view, Here is what I have done (and I plan to
deploy ) on my clients side :
# cat /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss netgroup: files sss hosts: files dns services: files sss
# cat /etc/sssd.conf [domain/default] ldap_id_use_start_tls = True cache_credentials = False ldap_search_base = dc=example,dc=fr krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts ldap_user_ssh_public_key = sshPublicKey dns_discovery_domain = example.fr
[sssd]
config_file_version = 2 services = nss, pam, ssh domains = default
[nss]
[pam]
[ssh]
Other than in sssd.conf, I have not declared any ldap server nor any information about the CA certificate location anywhere (no ldap uri or tls_cacertdir in /etc/pam_ldap.conf for example, nor anywhere).
I however have kept the start_tls directive in files when relevant.
Note : cacert needs to be added in ldap.conf for sudo-ldap to work in my case.
To be honnest my config is a bit more subtile on the DNS server side since I wanted a way to tune the discovery service so that the client find different weights for ldap prefered servers depending on where it is physically located : I use a zone per location to do that and play with the sssd "dns_discovery_domain" parameter.
I also tested the fallback : when I shut down the first ldap server, sssd seems to ask for the next one afeter one second : is that an hard coded sssd parameter ?
Any comment on that plan ?
--- Olivier
2013/9/25 Jakub Hrozek jhrozek@redhat.com
On Wed, Sep 25, 2013 at 09:00:42PM +0200, Michael Ströder wrote:
Jakub Hrozek wrote:
On Wed, Sep 25, 2013 at 08:22:57PM +0200, Michael Ströder wrote:
Hmm, I really wonder why SRV RRs are recommended over having a single
service
CNAME RR and maybe several A/AAAA RRs?
In my opinion, the biggest advantages are centrally defined failover using the "priority field" and the ability to evenly distribute load
using
"weight".
But really distributing the load would require adjusting the weight dynamically, wouldn't it?
Right, the SRV syntax merely allows you to say "direct 40% of traffic to box A, 40% to box B and 20% to box C. If neither of them is available, go to box D" _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Sorry, read in the previous :
# dig _ldap._tcp.example.fr SRV ... ;; ANSWER SECTION: _ldap._tcp.example.fr. 172800 IN SRV 10 0 389 ldap3.example.frhttp://ldap3.location1.example.fr . _ldap._tcp.example.fr. 172800 IN SRV 20 0 389 ldap1.example.frhttp://ldap1.location2.example.fr . _ldap._tcp.example.fr. 172800 IN SRV 30 0 389 ldap2.example.frhttp://ldap2.location3.example.fr .
2013/9/26 Olivier ldap@guillard.nom.fr
Hello Jakub and all,
may be the following could help : to be honnest, from an operational point of view I like the centralisation perspective offered by DNS discovery.
Any comment on these test/audit are welcomed.
for the following audit, the client side is rhel6-web.prod-int.example.fr: 10.yy.yy.17
Let see what says the dns about ldap service :
# dig _ldap._tcp.example.fr SRV
;; QUESTION SECTION: ;_ldap._tcp.example.fr. IN SRV
;; ANSWER SECTION: _ldap._tcp.example.fr. 172800 IN SRV 10 0 389 ldap3.location1.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 20 0 389 ldap1.location2.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 30 0 389 ldap2.location3.example.fr.
;; AUTHORITY SECTION: ...
;; ADDITIONAL SECTION: ldap3.example.fr. 172800 IN A 10.xx.xx.3 ldap1.example.fr. 172800 IN A 10.xx.xx.1 ldap2.example.fr. 172800 IN A 10.xx.xx.2
Now let's restart sssd:
# tshark -i eth1 not port 22
34.525938 10.xx.xx.17 -> 10.xx.xx.3 TLSv1 Application Data 34.525969 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Encrypted Alert 34.525982 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [FIN, ACK] Seq=1691 Ack=3075 Win=23296 Len=0 TSV=746424 TSER=60539402 34.526883 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36915 [FIN, ACK] Seq=3075 Ack=1692 Win=22016 Len=0 TSV=60551396 TSER=746424 34.526897 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [ACK] Seq=1692 Ack=3076 Win=23296 Len=0 TSV=746425 TSER=60551396 34.562795 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A rhel6-web.prod-int.example.fr 34.563250 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.yy.yy.17 35.568646 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query SRV _ldap._ tcp.example.fr
-->> HERE:
35.569170 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response SRV 20 0 389 ldap1.example.fr SRV 30 0 389 ldap2.example.fr SRV 10 0 389 ldap\ 3.example.fr 35.569421 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A ldap3.example.fr 35.569625 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.xx.xx.3 35.569774 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=747468 TSER=0 WS=6 35.570242 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 TSV=60552439 TSER=747468 WS=7 35.570257 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSV=747468 TSER=60552439 35.570594 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 35.570786 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [ACK] Seq=1 Ack=32 Win=14592 Len=0 TSV=60552440 TSER=747469 35.570987 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 35.570994 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=747469 TSER=60552440
-->> HERE:
35.578964 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 35.579506 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 35.579513 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 35.579537 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=747478 TSER=60552448 35.581211 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 35.581994 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec, Encrypted Handshake Message
--> sound's OK !
now let's have a look if I log in from civette.example.fr (10.zz.zz.94) :
# tshark -i eth1 not port 22 0.000000 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query PTR 94.zz.zz.10.in-addr.arpa 0.000306 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response PTR civette.example.fr 0.000507 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A civette.example.fr 0.000703 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.zz.zz.94 0.007700 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [PSH, ACK] Seq=1 Ack=1 Win=364 Len=565 TSV=845893 TSER=60553254 0.008561 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [PSH, ACK] Seq=1 Ack=566 Win=173 Len=53 TSV=60650865 TSER=845893 .... 4.674892 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSV=850561 TSER=60655531
-->> HERE :
4.675045 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 4.675213 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36918 [ACK] Seq=1 Ack=32 Win=14592 Len=0 TSV=60655531 TSER=850561 4.675473 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 4.675479 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=850561 TSER=60655532 4.675677 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 4.676129 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 4.676136 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 4.676176 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=850562 TSER=60655532 4.677304 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 4.678041 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec, Encrypted Handshake Message
....
--> to be honest I don't read fluently all this, but as far as I can see, it sounds to work very well (and I log in properly)
From a configuration point of view, Here is what I have done (and I plan to deploy ) on my clients side :
# cat /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss netgroup: files sss hosts: files dns services: files sss
# cat /etc/sssd.conf [domain/default] ldap_id_use_start_tls = True cache_credentials = False ldap_search_base = dc=example,dc=fr krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts ldap_user_ssh_public_key = sshPublicKey dns_discovery_domain = example.fr
[sssd]
config_file_version = 2 services = nss, pam, ssh domains = default
[nss]
[pam]
[ssh]
Other than in sssd.conf, I have not declared any ldap server nor any information about the CA certificate location anywhere (no ldap uri or tls_cacertdir in /etc/pam_ldap.conf for example, nor anywhere).
I however have kept the start_tls directive in files when relevant.
Note : cacert needs to be added in ldap.conf for sudo-ldap to work in my case.
To be honnest my config is a bit more subtile on the DNS server side since I wanted a way to tune the discovery service so that the client find different weights for ldap prefered servers depending on where it is physically located : I use a zone per location to do that and play with the sssd "dns_discovery_domain" parameter.
I also tested the fallback : when I shut down the first ldap server, sssd seems to ask for the next one afeter one second : is that an hard coded sssd parameter ?
Any comment on that plan ?
Olivier
2013/9/25 Jakub Hrozek jhrozek@redhat.com
On Wed, Sep 25, 2013 at 09:00:42PM +0200, Michael Ströder wrote:
Jakub Hrozek wrote:
On Wed, Sep 25, 2013 at 08:22:57PM +0200, Michael Ströder wrote:
Hmm, I really wonder why SRV RRs are recommended over having a
single service
CNAME RR and maybe several A/AAAA RRs?
In my opinion, the biggest advantages are centrally defined failover using the "priority field" and the ability to evenly distribute load
using
"weight".
But really distributing the load would require adjusting the weight dynamically, wouldn't it?
Right, the SRV syntax merely allows you to say "direct 40% of traffic to box A, 40% to box B and 20% to box C. If neither of them is available, go to box D" _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Sep 26, 2013 at 11:00:00AM +0200, Olivier wrote:
Hello Jakub and all,
may be the following could help : to be honnest, from an operational point of view I like the centralisation perspective offered by DNS discovery.
Any comment on these test/audit are welcomed.
for the following audit, the client side is rhel6-web.prod-int.example.fr: 10.yy.yy.17
Let see what says the dns about ldap service :
# dig _ldap._tcp.example.fr SRV
;; QUESTION SECTION: ;_ldap._tcp.example.fr. IN SRV
;; ANSWER SECTION: _ldap._tcp.example.fr. 172800 IN SRV 10 0 389 ldap3.location1.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 20 0 389 ldap1.location2.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 30 0 389 ldap2.location3.example.fr.
;; AUTHORITY SECTION: ...
;; ADDITIONAL SECTION: ldap3.example.fr. 172800 IN A 10.xx.xx.3 ldap1.example.fr. 172800 IN A 10.xx.xx.1 ldap2.example.fr. 172800 IN A 10.xx.xx.2
Now let's restart sssd:
# tshark -i eth1 not port 22
34.525938 10.xx.xx.17 -> 10.xx.xx.3 TLSv1 Application Data 34.525969 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Encrypted Alert 34.525982 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [FIN, ACK] Seq=1691 Ack=3075 Win=23296 Len=0 TSV=746424 TSER=60539402 34.526883 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36915 [FIN, ACK] Seq=3075 Ack=1692 Win=22016 Len=0 TSV=60551396 TSER=746424 34.526897 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [ACK] Seq=1692 Ack=3076 Win=23296 Len=0 TSV=746425 TSER=60551396 34.562795 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A rhel6-web.prod-int.example.fr 34.563250 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.yy.yy.17 35.568646 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query SRV _ldap._ tcp.example.fr
-->> HERE:
35.569170 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response SRV 20 0 389 ldap1.example.fr SRV 30 0 389 ldap2.example.fr SRV 10 0 389 ldap\ 3.example.fr 35.569421 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A ldap3.example.fr 35.569625 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.xx.xx.3 35.569774 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=747468 TSER=0 WS=6 35.570242 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 TSV=60552439 TSER=747468 WS=7 35.570257 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSV=747468 TSER=60552439 35.570594 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 35.570786 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [ACK] Seq=1 Ack=32 Win=14592 Len=0 TSV=60552440 TSER=747469 35.570987 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 35.570994 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=747469 TSER=60552440
-->> HERE:
35.578964 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 35.579506 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 35.579513 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 35.579537 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=747478 TSER=60552448 35.581211 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 35.581994 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec, Encrypted Handshake Message
--> sound's OK !
now let's have a look if I log in from civette.example.fr (10.zz.zz.94) :
# tshark -i eth1 not port 22 0.000000 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query PTR 94.zz.zz.10.in-addr.arpa 0.000306 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response PTR civette.example.fr 0.000507 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A civette.example.fr 0.000703 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.zz.zz.94 0.007700 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [PSH, ACK] Seq=1 Ack=1 Win=364 Len=565 TSV=845893 TSER=60553254 0.008561 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [PSH, ACK] Seq=1 Ack=566 Win=173 Len=53 TSV=60650865 TSER=845893 .... 4.674892 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=1 Ack=1 Win=14656 Len=0 TSV=850561 TSER=60655531
-->> HERE :
4.675045 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 4.675213 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36918 [ACK] Seq=1 Ack=32 Win=14592 Len=0 TSV=60655531 TSER=850561 4.675473 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 4.675479 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=850561 TSER=60655532 4.675677 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 4.676129 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 4.676136 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 4.676176 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=850562 TSER=60655532 4.677304 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 4.678041 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec, Encrypted Handshake Message
....
--> to be honest I don't read fluently all this, but as far as I can see, it sounds to work very well (and I log in properly)
From a configuration point of view, Here is what I have done (and I plan to deploy ) on my clients side :
# cat /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss netgroup: files sss hosts: files dns services: files sss
# cat /etc/sssd.conf [domain/default] ldap_id_use_start_tls = True cache_credentials = False ldap_search_base = dc=example,dc=fr krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts ldap_user_ssh_public_key = sshPublicKey dns_discovery_domain = example.fr
[sssd]
config_file_version = 2 services = nss, pam, ssh domains = default
[nss]
[pam]
[ssh]
Other than in sssd.conf, I have not declared any ldap server nor any information about the CA certificate location anywhere (no ldap uri or tls_cacertdir in /etc/pam_ldap.conf for example, nor anywhere).
I however have kept the start_tls directive in files when relevant.
Note : cacert needs to be added in ldap.conf for sudo-ldap to work in my case.
To be honnest my config is a bit more subtile on the DNS server side since I wanted a way to tune the discovery service so that the client find different weights for ldap prefered servers depending on where it is physically located : I use a zone per location to do that and play with the sssd "dns_discovery_domain" parameter.
I also tested the fallback : when I shut down the first ldap server, sssd seems to ask for the next one afeter one second : is that an hard coded sssd parameter ?
It should ask for the next one when the next request comes in. The timeout itself depends on the network conditions, ie if the LDAP server machine was reachable but not operational, then I would suspect the ldap_network_timeout would affect the time it takes to fail over.
Any comment on that plan ?
I think in general the setup looks good, you might just find the ldap_backup_uri parameter interesting for cases the DNS SRV records were not usable for one reason or another.
Jakub and all,
I think in general the setup looks good, you might just find the ldap_backup_uri parameter interesting for cases the DNS SRV records were not usable for one reason or another.
thanks for your precious time and help.
Olivier
2013/9/26 Jakub Hrozek jhrozek@redhat.com
On Thu, Sep 26, 2013 at 11:00:00AM +0200, Olivier wrote:
Hello Jakub and all,
may be the following could help : to be honnest, from an operational
point
of view I like the centralisation perspective offered by DNS discovery.
Any comment on these test/audit are welcomed.
for the following audit, the client side is rhel6-web.prod-int.example.fr: 10.yy.yy.17
Let see what says the dns about ldap service :
# dig _ldap._tcp.example.fr SRV
;; QUESTION SECTION: ;_ldap._tcp.example.fr. IN SRV
;; ANSWER SECTION: _ldap._tcp.example.fr. 172800 IN SRV 10 0 389 ldap3.location1.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 20 0 389 ldap1.location2.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 30 0 389 ldap2.location3.example.fr.
;; AUTHORITY SECTION: ...
;; ADDITIONAL SECTION: ldap3.example.fr. 172800 IN A 10.xx.xx.3 ldap1.example.fr. 172800 IN A 10.xx.xx.1 ldap2.example.fr. 172800 IN A 10.xx.xx.2
Now let's restart sssd:
# tshark -i eth1 not port 22
34.525938 10.xx.xx.17 -> 10.xx.xx.3 TLSv1 Application Data 34.525969 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Encrypted Alert 34.525982 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [FIN, ACK] Seq=1691 Ack=3075 Win=23296 Len=0 TSV=746424 TSER=60539402 34.526883 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36915 [FIN, ACK] Seq=3075 Ack=1692 Win=22016 Len=0 TSV=60551396 TSER=746424 34.526897 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [ACK] Seq=1692 Ack=3076 Win=23296 Len=0 TSV=746425 TSER=60551396 34.562795 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A rhel6-web.prod-int.example.fr 34.563250 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.yy.yy.17 35.568646 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query SRV _ldap._ tcp.example.fr
-->> HERE:
35.569170 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response SRV
20
0 389 ldap1.example.fr SRV 30 0 389 ldap2.example.fr SRV 10 0 389 ldap\ 3.example.fr 35.569421 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A ldap3.example.fr 35.569625 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.xx.xx.3 35.569774 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=747468 TSER=0 WS=6 35.570242 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 TSV=60552439 TSER=747468 WS=7 35.570257 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=1
Ack=1
Win=14656 Len=0 TSV=747468 TSER=60552439 35.570594 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 35.570786 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [ACK] Seq=1
Ack=32
Win=14592 Len=0 TSV=60552440 TSER=747469 35.570987 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 35.570994 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=747469 TSER=60552440
-->> HERE:
35.578964 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 35.579506 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 35.579513 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 35.579537 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=747478 TSER=60552448 35.581211 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 35.581994 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec,
Encrypted
Handshake Message
--> sound's OK !
now let's have a look if I log in from civette.example.fr (10.zz.zz.94)
:
# tshark -i eth1 not port 22 0.000000 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query PTR 94.zz.zz.10.in-addr.arpa 0.000306 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response PTR civette.example.fr 0.000507 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A civette.example.fr 0.000703 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.zz.zz.94 0.007700 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [PSH, ACK] Seq=1 Ack=1 Win=364 Len=565 TSV=845893 TSER=60553254 0.008561 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [PSH, ACK] Seq=1 Ack=566 Win=173 Len=53 TSV=60650865 TSER=845893 .... 4.674892 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=1
Ack=1
Win=14656 Len=0 TSV=850561 TSER=60655531
-->> HERE :
4.675045 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 4.675213 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36918 [ACK] Seq=1
Ack=32
Win=14592 Len=0 TSV=60655531 TSER=850561 4.675473 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 4.675479 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=850561 TSER=60655532 4.675677 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 4.676129 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 4.676136 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 4.676176 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=850562 TSER=60655532 4.677304 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 4.678041 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec,
Encrypted
Handshake Message
....
--> to be honest I don't read fluently all this, but as far as I can see, it sounds to work very well (and I log in properly)
From a configuration point of view, Here is what I have done (and I plan
to
deploy ) on my clients side :
# cat /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss netgroup: files sss hosts: files dns services: files sss
# cat /etc/sssd.conf [domain/default] ldap_id_use_start_tls = True cache_credentials = False ldap_search_base = dc=example,dc=fr krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts ldap_user_ssh_public_key = sshPublicKey dns_discovery_domain = example.fr
[sssd]
config_file_version = 2 services = nss, pam, ssh domains = default
[nss]
[pam]
[ssh]
Other than in sssd.conf, I have not declared any ldap server nor any information about the CA certificate location anywhere (no ldap uri or tls_cacertdir in /etc/pam_ldap.conf for example, nor anywhere).
I however have kept the start_tls directive in files when relevant.
Note : cacert needs to be added in ldap.conf for sudo-ldap to work in my case.
To be honnest my config is a bit more subtile on the DNS server side since I wanted a way to tune the discovery service so that the client find different weights for ldap prefered servers depending on where it is physically located : I use a zone per location to do that and play with the sssd "dns_discovery_domain" parameter.
I also tested the fallback : when I shut down the first ldap server, sssd seems to ask for the next one afeter one second : is that an hard coded sssd parameter ?
It should ask for the next one when the next request comes in. The timeout itself depends on the network conditions, ie if the LDAP server machine was reachable but not operational, then I would suspect the ldap_network_timeout would affect the time it takes to fail over.
Any comment on that plan ?
I think in general the setup looks good, you might just find the ldap_backup_uri parameter interesting for cases the DNS SRV records were not usable for one reason or another. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Here it comes again...
I have an issue with this deployment plan.
I use a script to deploy the client configuration. Outside of other things, the script write a fresh sssd.conf (including "dns_discovery_domain" and "ldap_backup_uri" as discussed), and then launch authconfig.
The problem is the following :
since my "fresh" sssd.conf doesn't include any "ldap_uri" (I don't need any since I want to use the DNS service discovery), then authconfig add this tuning.
When I look at the transactions with tshark, it sounds like sssd is ignoring the "dns_discovery_domain" (and use ldap servers as declared in "ldap_uri").
Do you confirm ?
Question : is there any way to avoid authconfig configuring "ldap_uri" in sssd.conf if "dns_discovery_domain" is already tuned ?
Other comment ?
Thanks,
--- Olivier
2013/9/26 Jakub Hrozek jhrozek@redhat.com
On Thu, Sep 26, 2013 at 11:00:00AM +0200, Olivier wrote:
Hello Jakub and all,
may be the following could help : to be honnest, from an operational
point
of view I like the centralisation perspective offered by DNS discovery.
Any comment on these test/audit are welcomed.
for the following audit, the client side is rhel6-web.prod-int.example.fr: 10.yy.yy.17
Let see what says the dns about ldap service :
# dig _ldap._tcp.example.fr SRV
;; QUESTION SECTION: ;_ldap._tcp.example.fr. IN SRV
;; ANSWER SECTION: _ldap._tcp.example.fr. 172800 IN SRV 10 0 389 ldap3.location1.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 20 0 389 ldap1.location2.example.fr. _ldap._tcp.example.fr. 172800 IN SRV 30 0 389 ldap2.location3.example.fr.
;; AUTHORITY SECTION: ...
;; ADDITIONAL SECTION: ldap3.example.fr. 172800 IN A 10.xx.xx.3 ldap1.example.fr. 172800 IN A 10.xx.xx.1 ldap2.example.fr. 172800 IN A 10.xx.xx.2
Now let's restart sssd:
# tshark -i eth1 not port 22
34.525938 10.xx.xx.17 -> 10.xx.xx.3 TLSv1 Application Data 34.525969 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Encrypted Alert 34.525982 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [FIN, ACK] Seq=1691 Ack=3075 Win=23296 Len=0 TSV=746424 TSER=60539402 34.526883 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36915 [FIN, ACK] Seq=3075 Ack=1692 Win=22016 Len=0 TSV=60551396 TSER=746424 34.526897 10.yy.yy.17 -> 10.xx.xx.3 TCP 36915 > ldap [ACK] Seq=1692 Ack=3076 Win=23296 Len=0 TSV=746425 TSER=60551396 34.562795 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A rhel6-web.prod-int.example.fr 34.563250 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.yy.yy.17 35.568646 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query SRV _ldap._ tcp.example.fr
-->> HERE:
35.569170 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response SRV
20
0 389 ldap1.example.fr SRV 30 0 389 ldap2.example.fr SRV 10 0 389 ldap\ 3.example.fr 35.569421 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A ldap3.example.fr 35.569625 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.xx.xx.3 35.569774 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [SYN] Seq=0 Win=14600 Len=0 MSS=1460 TSV=747468 TSER=0 WS=6 35.570242 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [SYN, ACK] Seq=0 Ack=1 Win=14480 Len=0 MSS=1460 TSV=60552439 TSER=747468 WS=7 35.570257 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=1
Ack=1
Win=14656 Len=0 TSV=747468 TSER=60552439 35.570594 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 35.570786 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [ACK] Seq=1
Ack=32
Win=14592 Len=0 TSV=60552440 TSER=747469 35.570987 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 35.570994 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=747469 TSER=60552440
-->> HERE:
35.578964 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 35.579506 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 35.579513 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 35.579537 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=747478 TSER=60552448 35.581211 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 35.581994 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec,
Encrypted
Handshake Message
--> sound's OK !
now let's have a look if I log in from civette.example.fr (10.zz.zz.94)
:
# tshark -i eth1 not port 22 0.000000 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query PTR 94.zz.zz.10.in-addr.arpa 0.000306 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response PTR civette.example.fr 0.000507 10.yy.yy.17 -> 10.yy.yy.162 DNS Standard query A civette.example.fr 0.000703 10.yy.yy.162 -> 10.yy.yy.17 DNS Standard query response A 10.zz.zz.94 0.007700 10.yy.yy.17 -> 10.xx.xx.3 TCP 36916 > ldap [PSH, ACK] Seq=1 Ack=1 Win=364 Len=565 TSV=845893 TSER=60553254 0.008561 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36916 [PSH, ACK] Seq=1 Ack=566 Win=173 Len=53 TSV=60650865 TSER=845893 .... 4.674892 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=1
Ack=1
Win=14656 Len=0 TSV=850561 TSER=60655531
-->> HERE :
4.675045 10.yy.yy.17 -> 10.xx.xx.3 LDAP extendedReq(1) LDAP_START_TLS_OID 4.675213 10.xx.xx.3 -> 10.yy.yy.17 TCP ldap > 36918 [ACK] Seq=1
Ack=32
Win=14592 Len=0 TSV=60655531 TSER=850561 4.675473 10.xx.xx.3 -> 10.yy.yy.17 LDAP extendedResp(1) [LDAP_START_TLS_OID responseName missing] 4.675479 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=32 Ack=15 Win=14656 Len=0 TSV=850561 TSER=60655532 4.675677 10.yy.yy.17 -> 10.xx.xx.3 SSL Client Hello 4.676129 10.xx.xx.3 -> 10.yy.yy.17 TCP [TCP segment of a reassembled PDU] 4.676136 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Server Hello, Certificate, Certificate Request, Server Hello Done 4.676176 10.yy.yy.17 -> 10.xx.xx.3 TCP 36918 > ldap [ACK] Seq=134 Ack=2005 Win=20416 Len=0 TSV=850562 TSER=60655532 4.677304 10.yy.yy.17 -> 10.xx.xx.3 TLSv1 Certificate, Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message 4.678041 10.xx.xx.3 -> 10.yy.yy.17 TLSv1 Change Cipher Spec,
Encrypted
Handshake Message
....
--> to be honest I don't read fluently all this, but as far as I can see, it sounds to work very well (and I log in properly)
From a configuration point of view, Here is what I have done (and I plan
to
deploy ) on my clients side :
# cat /etc/nsswitch.conf passwd: files sss shadow: files sss group: files sss netgroup: files sss hosts: files dns services: files sss
# cat /etc/sssd.conf [domain/default] ldap_id_use_start_tls = True cache_credentials = False ldap_search_base = dc=example,dc=fr krb5_realm = EXAMPLE.COM krb5_server = kerberos.example.com id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_tls_cacertdir = /etc/openldap/cacerts ldap_user_ssh_public_key = sshPublicKey dns_discovery_domain = example.fr
[sssd]
config_file_version = 2 services = nss, pam, ssh domains = default
[nss]
[pam]
[ssh]
Other than in sssd.conf, I have not declared any ldap server nor any information about the CA certificate location anywhere (no ldap uri or tls_cacertdir in /etc/pam_ldap.conf for example, nor anywhere).
I however have kept the start_tls directive in files when relevant.
Note : cacert needs to be added in ldap.conf for sudo-ldap to work in my case.
To be honnest my config is a bit more subtile on the DNS server side since I wanted a way to tune the discovery service so that the client find different weights for ldap prefered servers depending on where it is physically located : I use a zone per location to do that and play with the sssd "dns_discovery_domain" parameter.
I also tested the fallback : when I shut down the first ldap server, sssd seems to ask for the next one afeter one second : is that an hard coded sssd parameter ?
It should ask for the next one when the next request comes in. The timeout itself depends on the network conditions, ie if the LDAP server machine was reachable but not operational, then I would suspect the ldap_network_timeout would affect the time it takes to fail over.
Any comment on that plan ?
I think in general the setup looks good, you might just find the ldap_backup_uri parameter interesting for cases the DNS SRV records were not usable for one reason or another. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 10:39 AM, Olivier wrote:
Here it comes again...
I have an issue with this deployment plan.
I use a script to deploy the client configuration. Outside of other things, the script write a fresh sssd.conf (including "dns_discovery_domain" and "ldap_backup_uri" as discussed), and then launch authconfig.
The problem is the following :
since my "fresh" sssd.conf doesn't include any "ldap_uri" (I don't need any since I want to use the DNS service discovery), then authconfig add this tuning.
When I look at the transactions with tshark, it sounds like sssd is ignoring the "dns_discovery_domain" (and use ldap servers as declared in "ldap_uri").
Do you confirm ?
Question : is there any way to avoid authconfig configuring "ldap_uri" in sssd.conf if "dns_discovery_domain" is already tuned ?
Other comment ?
This sounds like a pretty clear bug in authconfig. Would you mind filing it at https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=authc... please?
Hello Stephen,
this is done : https://bugzilla.redhat.com/show_bug.cgi?id=1018189
I have reported it as an authconfig bug, I think it might also be something to be considered at sssd level : should'nt sssd use "dns_discovery_domain" to look for ldap server rather than "ldap_uri" if borth parameters are declared in sssd.conf ?
--- Olivier
2013/10/10 Stephen Gallagher sgallagh@redhat.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/10/2013 10:39 AM, Olivier wrote:
Here it comes again...
I have an issue with this deployment plan.
I use a script to deploy the client configuration. Outside of other things, the script write a fresh sssd.conf (including "dns_discovery_domain" and "ldap_backup_uri" as discussed), and then launch authconfig.
The problem is the following :
since my "fresh" sssd.conf doesn't include any "ldap_uri" (I don't need any since I want to use the DNS service discovery), then authconfig add this tuning.
When I look at the transactions with tshark, it sounds like sssd is ignoring the "dns_discovery_domain" (and use ldap servers as declared in "ldap_uri").
Do you confirm ?
Question : is there any way to avoid authconfig configuring "ldap_uri" in sssd.conf if "dns_discovery_domain" is already tuned ?
Other comment ?
This sounds like a pretty clear bug in authconfig. Would you mind filing it at
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=authc... please?
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJW9OQACgkQeiVVYja6o6PlRgCfbbL5kS5i/6MD1qanH13Mq4Mw ZeAAn1yDCxlj+VGxbLzVx8vhr8E04zKc =AGMd -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Fri, 11 Oct 2013 14:07:31 +0200 Olivier ldap@guillard.nom.fr wrote
I have reported it as an authconfig bug, I think it might also be something to be considered at sssd level : should'nt sssd use "dns_discovery_domain" to look for ldap server rather than "ldap_uri" if borth parameters are declared in sssd.conf ?
Well, why not just use LDAP URI without hostport portion for initiating a DNS-based server lookup:
ldapuri ldap:///dc=example,dc=com
Could even suppport LDAPS
ldapuri ldaps:///dc=example,dc=com
Ciao, Michael.
Hello Mikael,
I don't know if sssd.conf support this syntax, nor authconfig, but that would not work for me anyway.
authconfig generates other configurations than sssd.conf such as pam_ldap.conf for example (which does not support dns discovery).
That's why I need to launch authconfig with explicit ldap servers (and I don't want them to be declared in ldap_uri).
--- Olivier
2013/10/11 Michael Ströder michael@stroeder.com
On Fri, 11 Oct 2013 14:07:31 +0200 Olivier ldap@guillard.nom.fr wrote
I have reported it as an authconfig bug, I think it might also be
something
to be considered at sssd level : should'nt sssd use
"dns_discovery_domain"
to look for ldap server rather than "ldap_uri" if borth parameters are declared in sssd.conf ?
Well, why not just use LDAP URI without hostport portion for initiating a DNS-based server lookup:
ldapuri ldap:///dc=example,dc=com
Could even suppport LDAPS
ldapuri ldaps:///dc=example,dc=com
Ciao, Michael.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/11/2013 08:41 AM, Olivier wrote:
Hello Mikael,
I don't know if sssd.conf support this syntax, nor authconfig, but that would not work for me anyway.
authconfig generates other configurations than sssd.conf such as pam_ldap.conf for example (which does not support dns discovery).
That's why I need to launch authconfig with explicit ldap servers (and I don't want them to be declared in ldap_uri).
Why are you configuring pam_ldap if you're using SSSD? That doesn't make any sense.
BTW you are perfectly right, I don't need that anymore since I now use pam_sss.so instead of pam_ldap.so
Something I had forgotten to clean : thanks.
I still see ldap servers passed to authconfig present in : sudo-ldap (I have not managed to use sssd to gather rules yet) and openldap.conf
So it sounds like I might manage to remove ldap servers declaration for authconfig (once I'll manage to use sssd for sudo).
Best
--- Olivier
2013/10/11 Stephen Gallagher sgallagh@redhat.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/11/2013 08:41 AM, Olivier wrote:
Hello Mikael,
I don't know if sssd.conf support this syntax, nor authconfig, but that would not work for me anyway.
authconfig generates other configurations than sssd.conf such as pam_ldap.conf for example (which does not support dns discovery).
That's why I need to launch authconfig with explicit ldap servers (and I don't want them to be declared in ldap_uri).
Why are you configuring pam_ldap if you're using SSSD? That doesn't make any sense.
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJX9lkACgkQeiVVYja6o6MK+ACeKqoFBNgp85yorZ1TnP2R6+1c 870An1EBiYZbfpowfFKTvkyaDY3H1xR4 =mg52 -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/11/2013 08:07 AM, Olivier wrote:
Hello Stephen,
this is done : https://bugzilla.redhat.com/show_bug.cgi?id=1018189
I have reported it as an authconfig bug, I think it might also be something to be considered at sssd level : should'nt sssd use "dns_discovery_domain" to look for ldap server rather than "ldap_uri" if borth parameters are declared in sssd.conf ?
No, because they're not directly related. You could be using DNS discovery only for Kerberos (for example). The idea is that if you have ldap_uri specified, you're doing it intentionally to override DNS.
Ah ! I see.
Thanks
2013/10/11 Stephen Gallagher sgallagh@redhat.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10/11/2013 08:07 AM, Olivier wrote:
Hello Stephen,
this is done : https://bugzilla.redhat.com/show_bug.cgi?id=1018189
I have reported it as an authconfig bug, I think it might also be something to be considered at sssd level : should'nt sssd use "dns_discovery_domain" to look for ldap server rather than "ldap_uri" if borth parameters are declared in sssd.conf ?
No, because they're not directly related. You could be using DNS discovery only for Kerberos (for example). The idea is that if you have ldap_uri specified, you're doing it intentionally to override DNS. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlJX7VAACgkQeiVVYja6o6Mw7QCdG/QZW/J+s3MS9UOyYo7A1sGH q1IAoIxlfr/0WOnQLdgYgx7maBKSnjWd =i0p+ -----END PGP SIGNATURE----- _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Jakub Hrozek wrote:
On Wed, Sep 25, 2013 at 08:22:57PM +0200, Michael Ströder wrote:
Hmm, I really wonder why SRV RRs are recommended over having a single service CNAME RR and maybe several A/AAAA RRs?
In my opinion, the biggest advantages are centrally defined failover using the "priority field" and the ability to evenly distribute load using "weight".
But still my concerns regarding the TLS hostname check is unanswered.
Ciao, Michael.
But still my concerns regarding the TLS hostname check is unanswered.
DNSSEC ?
Best
2013/9/26 Michael Ströder michael@stroeder.com
Jakub Hrozek wrote:
On Wed, Sep 25, 2013 at 08:22:57PM +0200, Michael Ströder wrote:
Hmm, I really wonder why SRV RRs are recommended over having a single
service
CNAME RR and maybe several A/AAAA RRs?
In my opinion, the biggest advantages are centrally defined failover using the "priority field" and the ability to evenly distribute load
using
"weight".
But still my concerns regarding the TLS hostname check is unanswered.
Ciao, Michael.
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/25/2013 02:22 PM, Michael Ströder wrote:
Stephen Gallagher wrote:
On 09/25/2013 09:06 AM, Olivier wrote:
if I may an additionnal question : would the sssd fallback mecanism work with the DNS discovery ?
Aka, if I'd configure this in the DNS :
_ldap._tcp.example.com http://tcp.example.com. IN SRV 10 0 389 ldap1.example.com http://ldap1.example.com. _ldap._tcp.example.com http://tcp.example.com. IN SRV 20 0 389 ldap2.example.com http://ldap2.example.com.
will sssd fallback properly to ldap2 if ldap1 does not respond ?
Yes, and in fact this is the recommended mechanism for setting up SSSD in your environment, since you need only to update the DNS records and all of your clients will have access to a new set of LDAP servers (i.e. if you provision additional ones and/or retire others).
Hmm, I really wonder why SRV RRs are recommended over having a single service CNAME RR and maybe several A/AAAA RRs?
Especially I'm concerned whether the TLS hostname check is properley done in case of TLS connections (StartTLS ext.op or LDAPS). Because a hostname check has to be performed against *a-priori* knowledge of the client to fight against MITM attacks with DNS spoofing.
So if you're local configuration just knows "example.com" the server cert MUST have a subject alt name with that domain name. I doubt that LDAP clients really check this.
Would you mind rephrasing this question? I'm not really sure I understand. The expectation with the LDAP server is that it would have an x.509 server certificate issued for its fully-qualified domain name. In the example above, that would be ldap1.example.com and ldap2.example.com.
If those referenced A records are also a load balancer pointing to other machines behind it, then yes. ldap1-1.example.com and ldap1-2.example.com would need their cert to have a subject alt name with the FQDN ldap.example.com since that's the name they would addressed by.
And yes, SSSD *does* check this carefully. Under the hood, we do the following (to explain in possible unnecessary detail; I'm going to gloss over the failover and assume that all servers are working).
1) Look up the SRV record. 2) Look up the A/AAAA record for the FQDN referenced in the SRV record 3) Open a socket to the first returned IP address 4) Hand off the file descriptor of this socket to the openldap client libraries, specifying the URI to the libraries as LDAP[s]://ldap1.example.com 5) The ldap client library will open the connection and request the server certificate. 6) The ldap client library will validate the certificate first that either the subject or subject alt name matches the URI we gave it and then will verify that the server certificate is appropriately signed by a trusted authority.
Stephen Gallagher wrote:
On 09/25/2013 02:22 PM, Michael Ströder wrote:
Stephen Gallagher wrote:
On 09/25/2013 09:06 AM, Olivier wrote:
if I may an additionnal question : would the sssd fallback mecanism work with the DNS discovery ?
Aka, if I'd configure this in the DNS :
_ldap._tcp.example.com http://tcp.example.com. IN SRV 10 0 389 ldap1.example.com http://ldap1.example.com. _ldap._tcp.example.com http://tcp.example.com. IN SRV 20 0 389 ldap2.example.com http://ldap2.example.com.
will sssd fallback properly to ldap2 if ldap1 does not respond ?
Yes, and in fact this is the recommended mechanism for setting up SSSD in your environment, since you need only to update the DNS records and all of your clients will have access to a new set of LDAP servers (i.e. if you provision additional ones and/or retire others).
Hmm, I really wonder why SRV RRs are recommended over having a single service CNAME RR and maybe several A/AAAA RRs?
Especially I'm concerned whether the TLS hostname check is properley done in case of TLS connections (StartTLS ext.op or LDAPS). Because a hostname check has to be performed against *a-priori* knowledge of the client to fight against MITM attacks with DNS spoofing.
So if you're local configuration just knows "example.com" the server cert MUST have a subject alt name with that domain name. I doubt that LDAP clients really check this.
Would you mind rephrasing this question? I'm not really sure I understand. The expectation with the LDAP server is that it would have an x.509 server certificate issued for its fully-qualified domain name. In the example above, that would be ldap1.example.com and ldap2.example.com.
I'd like to be more precise here: No matter what the FQDN of the server at OS level is the client expects the hostname it used for making the connection.
Example: Client configuration contains ldap.example.com. The FQDN of the LDAP server is srv1.example.com. In DNS ldap.example.com is a CNAME pointing to ldapsrv1.example.com which in turn has a A RR for the IP address of the service interface of srv1.example.com where the LDAP server is listening. => the client simply has to check whether ldap.example.com is in the server cert. This protects against DNS spoofing attacks (provided cert validation etc. is done right).
And yes, SSSD *does* check this carefully. Under the hood, we do the following (to explain in possible unnecessary detail; I'm going to gloss over the failover and assume that all servers are working).
- Look up the SRV record.
This could be spoofed.
- Look up the A/AAAA record for the FQDN referenced in the SRV record
- Open a socket to the first returned IP address
- Hand off the file descriptor of this socket to the openldap client
libraries, specifying the URI to the libraries as LDAP[s]://ldap1.example.com 5) The ldap client library will open the connection and request the server certificate. 6) The ldap client library will validate the certificate first that either the subject or subject alt name matches the URI we gave it and then will verify that the server certificate is appropriately signed by a trusted authority.
The client should check two things: 1. The usual hostname check comparing a hostname derived from one of the SRV RRs to protect against the spoofing of the CNAME/A lookup (CN or subjectAltName). 2. A service URL check, e.g. ldap:///dc=example,dc=com to protect against the spoofing of the SRV lookup (only subjectAltName).
Unfortunately the LDAP part of RFC 6125 does not say something about this:
http://tools.ietf.org/html/rfc6125#appendix-B.3
Also the SRV-ID in RFC 6125 is not really suitable for SRV RRs in case of LDAP:
http://tools.ietf.org/html/rfc6125#section-6.5
Ciao, Michael.
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Michael Ströder -
Olivier -
Stephen Gallagher