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