It should ask for the next one when the next request comes in. TheOn 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 ?
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
>
> Any comment on that plan ?
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