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.
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.