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