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 workin 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 ?
---Olivier2013/9/25 Jakub Hrozek <jhrozek@redhat.com>
Right, the SRV syntax merely allows you to say "direct 40% of traffic toOn 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?
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