sssd.conf, authconfig and ldap_uri

[Olivier]

Hello everyone,

I launch "authconfig" within a script to setup my redhat6 boxes.

I noticed that authconfig does not set up sssd.conf properly :
https://bugzilla.redhat.com/show_bug.cgi?id=874527

but the bug is declared as "closed" ?

First question :

could anyone confirm that authconfig does *not* configure
sssd.conf with "--enablesss" and  "--enablesssdauth" and
that I therefore need to configure that file myself (by hand
or within my script) ?

Second question:

I noticed that sssd seemed to work properly even without
declaring the "ldap_uri" parameter within sssd.conf. Could
anyone confirm that this parameter is not necessary and
where does sssd collect the list of ldap servers to query
in that case, ldap.conf ?

Thank you for any help,

Best regards,

---
Olivier

[Jakub Hrozek]

On Wed, Sep 25, 2013 at 11:42:15AM +0200, Olivier wrote:
>  Hello everyone,
>  
>  I launch "authconfig" within a script to setup my redhat6 boxes.
>  
>  I noticed that authconfig does not set up sssd.conf properly :
>  https://bugzilla.redhat.com/show_bug.cgi?id=874527
>  
>  but the bug is declared as "closed" ?
>  
>  First question :
>  
>  could anyone confirm that authconfig does *not* configure
>  sssd.conf with "--enablesss" and  "--enablesssdauth" and
>  that I therefore need to configure that file myself (by hand
>  or within my script) ? 
The switches --enablesss and --enablesssdauth are meant for the case
where the admin creates the sssd.conf manually and only wants the
authconfig to setup the NSS and PAM stacks for him. So with the latest
version, authconfig --enablesssdauth --enablesss should not touch the
sssd.conf at all.

>  
>  Second question:
>  
>  I noticed that sssd seemed to work properly even without
>  declaring the "ldap_uri" parameter within sssd.conf. Could
>  anyone confirm that this parameter is not necessary and
>  where does sssd collect the list of ldap servers to query
>  in that case, ldap.conf ? 
Yes, if the ldap_uri parameter is missing, then the SSSD falls back to
DNS SRV discovery. As the sssd-ldap man page says:

"""
ldap_uri, ldap_backup_uri (string):
 If neither option is specified, service discovery is enabled.
"""

[Olivier]

Thank you Jakub,

if I may an additionnal question : would the sssd fallback mecanism
work with the DNS discovery ?

Aka, if I'd configure this in the DNS :

_ldap._tcp.example.com.	IN	SRV	10 0 389 ldap1.example.com.
_ldap._tcp.example.com.	IN	SRV	20 0 389 ldap2.example.com.

will sssd fallback properly to ldap2 if ldap1 does not respond ?

thanks,

---
Olivier




2013/9/25 Jakub Hrozek <jhrozek(a)redhat.com&gt;

>  On Wed, Sep 25, 2013 at 11:42:15AM +0200, Olivier wrote:
>  > Hello everyone,
>  >
>  > I launch "authconfig" within a script to setup my redhat6 boxes.
>  >
>  > I noticed that authconfig does not set up sssd.conf properly :
>  > https://bugzilla.redhat.com/show_bug.cgi?id=874527
>  >
>  > but the bug is declared as "closed" ?
>  >
>  > First question :
>  >
>  > could anyone confirm that authconfig does *not* configure
>  > sssd.conf with "--enablesss" and  "--enablesssdauth" and
>  > that I therefore need to configure that file myself (by hand
>  > or within my script) ?
>
>  The switches --enablesss and --enablesssdauth are meant for the case
>  where the admin creates the sssd.conf manually and only wants the
>  authconfig to setup the NSS and PAM stacks for him. So with the latest
>  version, authconfig --enablesssdauth --enablesss should not touch the
>  sssd.conf at all.
>
>  >
>  > Second question:
>  >
>  > I noticed that sssd seemed to work properly even without
>  > declaring the "ldap_uri" parameter within sssd.conf. Could
>  > anyone confirm that this parameter is not necessary and
>  > where does sssd collect the list of ldap servers to query
>  > in that case, ldap.conf ?
>
>  Yes, if the ldap_uri parameter is missing, then the SSSD falls back to
>  DNS SRV discovery. As the sssd-ldap man page says:
>
>  """
>  ldap_uri, ldap_backup_uri (string):
>   If neither option is specified, service discovery is enabled.
>  """
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/25/2013 09:06 AM, Olivier wrote:
>  Thank you Jakub,
>  
>  if I may an additionnal question : would the sssd fallback
>  mecanism work with the DNS discovery ?
>  
>  Aka, if I'd configure this in the DNS :
>  
>  _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	10 0 389
>  ldap1.example.com <http://ldap1.example.com>;. 
>  _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	20 0 389
>  ldap2.example.com <http://ldap2.example.com>;.
>  
>  will sssd fallback properly to ldap2 if ldap1 does not respond ?
>   
Yes, and in fact this is the recommended mechanism for setting up SSSD
in your environment, since you need only to update the DNS records and
all of your clients will have access to a new set of LDAP servers
(i.e. if you provision additional ones and/or retire others).

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJC4i4ACgkQeiVVYja6o6MJHwCgjIWXzEHZ/YmzGpssrFBL3m70
> p48AmwdMfKIBVD25/4c3KIHrMETPngat
> =jvYU
> -----END PGP SIGNATURE-----

[Michael Ströder]

Stephen Gallagher wrote:
>  On 09/25/2013 09:06 AM, Olivier wrote:
> > if I may an additionnal question : would the sssd fallback
> > mecanism work with the DNS discovery ?
>  
> > Aka, if I'd configure this in the DNS :
>  
> > _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	10 0 389
> > ldap1.example.com <http://ldap1.example.com>;. 
> > _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	20 0 389
> > ldap2.example.com <http://ldap2.example.com>;.
>  
> > will sssd fallback properly to ldap2 if ldap1 does not respond ?
>  
>  Yes, and in fact this is the recommended mechanism for setting up SSSD
>  in your environment, since you need only to update the DNS records and
>  all of your clients will have access to a new set of LDAP servers
>  (i.e. if you provision additional ones and/or retire others). 
Hmm, I really wonder why SRV RRs are recommended over having a single service
CNAME RR and maybe several A/AAAA RRs?

Especially I'm concerned whether the TLS hostname check is properley done in
case of TLS connections (StartTLS ext.op or LDAPS). Because a hostname check
has to be performed against *a-priori* knowledge of the client to fight
against MITM attacks with DNS spoofing.

So if you're local configuration just knows "example.com" the server cert
MUST
have a subject alt name with that domain name. I doubt that LDAP clients
really check this.

Ciao, Michael.

[Jakub Hrozek]

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

[Michael Ströder]

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?

Ciao, Michael.

[Jakub Hrozek]

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"

[Olivier]

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(a)redhat.com&gt;

>  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(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Olivier]

Sorry, read in the previous :

# dig _ldap._tcp.example.fr SRV
...
;; ANSWER SECTION:
_ldap._tcp.example.fr. 172800   IN      SRV     10 0 389
ldap3.example.fr<http://ldap3.location1.example.fr>
.
_ldap._tcp.example.fr. 172800   IN      SRV     20 0 389
ldap1.example.fr<http://ldap1.location2.example.fr>
.
_ldap._tcp.example.fr. 172800   IN      SRV     30 0 389
ldap2.example.fr<http://ldap2.location3.example.fr>
.





2013/9/26 Olivier <ldap(a)guillard.nom.fr&gt;

>  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(a)redhat.com&gt;
>
> > 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(a)lists.fedorahosted.org
> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
> >
>
>

[Jakub Hrozek]

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.

[Olivier]

Jakub and all,

>  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. 
thanks for your precious time and help.

Olivier


2013/9/26 Jakub Hrozek <jhrozek(a)redhat.com&gt;

>  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(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Olivier]

Here it comes again...

I have an issue with this deployment plan.

I use a script to deploy the client configuration. Outside of other things,
the script write a fresh sssd.conf (including "dns_discovery_domain" and
"ldap_backup_uri" as discussed), and then launch authconfig.

The problem is the following :

since my "fresh" sssd.conf doesn't include any "ldap_uri" (I
don't need
any since I want to use the DNS service discovery), then authconfig
add this tuning.

When I look at the transactions with tshark, it sounds like sssd is
ignoring the "dns_discovery_domain" (and use ldap servers as declared
in "ldap_uri").

Do you confirm ?

Question : is there any way to avoid authconfig configuring "ldap_uri"
in sssd.conf if "dns_discovery_domain" is already tuned ?

Other comment ?

Thanks,

---
Olivier














2013/9/26 Jakub Hrozek <jhrozek(a)redhat.com&gt;

>  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(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/10/2013 10:39 AM, Olivier wrote:
>  Here it comes again...
>  
>  I have an issue with this deployment plan.
>  
>  I use a script to deploy the client configuration. Outside of other
>  things, the script write a fresh sssd.conf (including
>  "dns_discovery_domain" and "ldap_backup_uri" as discussed), and
>  then launch authconfig.
>  
>  The problem is the following :
>  
>  since my "fresh" sssd.conf doesn't include any "ldap_uri" (I
> don't
>  need any since I want to use the DNS service discovery), then
>  authconfig add this tuning.
>  
>  When I look at the transactions with tshark, it sounds like sssd
>  is ignoring the "dns_discovery_domain" (and use ldap servers as
>  declared in "ldap_uri").
>  
>  Do you confirm ?
>  
>  Question : is there any way to avoid authconfig configuring
>  "ldap_uri" in sssd.conf if "dns_discovery_domain" is already tuned
>  ?
>  
>  Other comment ?
>   

This sounds like a pretty clear bug in authconfig. Would you mind
filing it at
https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=au...
please?

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJW9OQACgkQeiVVYja6o6PlRgCfbbL5kS5i/6MD1qanH13Mq4Mw
> ZeAAn1yDCxlj+VGxbLzVx8vhr8E04zKc
> =AGMd
> -----END PGP SIGNATURE-----

[Olivier]

Hello Stephen,

this is done : https://bugzilla.redhat.com/show_bug.cgi?id=1018189

I have reported it as an authconfig bug, I think it might also be something
to be considered at sssd level : should'nt sssd use "dns_discovery_domain"
to look for ldap server rather than "ldap_uri" if borth parameters are
declared
in sssd.conf ?

---
Olivier






2013/10/10 Stephen Gallagher <sgallagh(a)redhat.com&gt;

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 10/10/2013 10:39 AM, Olivier wrote:
>  > Here it comes again...
>  >
>  > I have an issue with this deployment plan.
>  >
>  > I use a script to deploy the client configuration. Outside of other
>  > things, the script write a fresh sssd.conf (including
>  > "dns_discovery_domain" and "ldap_backup_uri" as discussed), and
>  > then launch authconfig.
>  >
>  > The problem is the following :
>  >
>  > since my "fresh" sssd.conf doesn't include any "ldap_uri" (I
> don't
>  > need any since I want to use the DNS service discovery), then
>  > authconfig add this tuning.
>  >
>  > When I look at the transactions with tshark, it sounds like sssd
>  > is ignoring the "dns_discovery_domain" (and use ldap servers as
>  > declared in "ldap_uri").
>  >
>  > Do you confirm ?
>  >
>  > Question : is there any way to avoid authconfig configuring
>  > "ldap_uri" in sssd.conf if "dns_discovery_domain" is already
> tuned
>  > ?
>  >
>  > Other comment ?
>  >
>
>
>  This sounds like a pretty clear bug in authconfig. Would you mind
>  filing it at
>
>  https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=au...
>  please?
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.14 (GNU/Linux)
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >  iEYEARECAAYFAlJW9OQACgkQeiVVYja6o6PlRgCfbbL5kS5i/6MD1qanH13Mq4Mw
> >  ZeAAn1yDCxlj+VGxbLzVx8vhr8E04zKc
> >  =AGMd
> >  -----END PGP SIGNATURE----- 
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Michael Ströder]

On Fri, 11 Oct 2013 14:07:31 +0200 Olivier <ldap(a)guillard.nom.fr&gt; wrote
>  I have reported it as an authconfig bug, I think it might also be
> something
>  to be considered at sssd level : should'nt sssd use "dns_discovery_domain"
>  to look for ldap server rather than "ldap_uri" if borth parameters are
>  declared
>  in sssd.conf ? 
Well, why not just use LDAP URI without hostport portion for initiating a
DNS-based server lookup:

ldapuri ldap:///dc=example,dc=com

Could even suppport LDAPS

ldapuri ldaps:///dc=example,dc=com

Ciao, Michael.

[Olivier]

Hello Mikael,

I don't know if sssd.conf support this syntax, nor authconfig, but
that would not work for me anyway.

authconfig generates other configurations than sssd.conf such as
pam_ldap.conf for example (which does not support dns discovery).

That's why I need to launch authconfig with explicit ldap servers
(and I don't want them to be declared in ldap_uri).

---
Olivier





2013/10/11 Michael Ströder <michael(a)stroeder.com&gt;

>  On Fri, 11 Oct 2013 14:07:31 +0200 Olivier
> <ldap(a)guillard.nom.fr&gt; wrote
>  > I have reported it as an authconfig bug, I think it might also be
>  something
>  > to be considered at sssd level : should'nt sssd use
>  "dns_discovery_domain"
>  > to look for ldap server rather than "ldap_uri" if borth parameters are
>  > declared
>  > in sssd.conf ?
>
>  Well, why not just use LDAP URI without hostport portion for initiating a
>  DNS-based server lookup:
>
>  ldapuri ldap:///dc=example,dc=com
>
>  Could even suppport LDAPS
>
>  ldapuri ldaps:///dc=example,dc=com
>
>  Ciao, Michael.
>
>
>

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/11/2013 08:41 AM, Olivier wrote:
>  Hello Mikael,
>  
>  I don't know if sssd.conf support this syntax, nor authconfig, but 
>  that would not work for me anyway.
>  
>  authconfig generates other configurations than sssd.conf such as 
>  pam_ldap.conf for example (which does not support dns discovery).
>  
>  That's why I need to launch authconfig with explicit ldap servers 
>  (and I don't want them to be declared in ldap_uri).
>   

Why are you configuring pam_ldap if you're using SSSD? That doesn't
make any sense.

> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJX9lkACgkQeiVVYja6o6MK+ACeKqoFBNgp85yorZ1TnP2R6+1c
> 870An1EBiYZbfpowfFKTvkyaDY3H1xR4
> =mg52
> -----END PGP SIGNATURE-----

[Olivier]

BTW you are perfectly right, I don't need that anymore since
I now use pam_sss.so instead of pam_ldap.so

Something I had forgotten to clean : thanks.

I still see ldap servers passed to authconfig present in : sudo-ldap
(I have not managed to use sssd to gather rules yet) and openldap.conf

So it sounds like I might manage to remove ldap servers declaration
for authconfig (once I'll manage to use sssd for sudo).

Best

---
Olivier



2013/10/11 Stephen Gallagher <sgallagh(a)redhat.com&gt;

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 10/11/2013 08:41 AM, Olivier wrote:
>  > Hello Mikael,
>  >
>  > I don't know if sssd.conf support this syntax, nor authconfig, but
>  > that would not work for me anyway.
>  >
>  > authconfig generates other configurations than sssd.conf such as
>  > pam_ldap.conf for example (which does not support dns discovery).
>  >
>  > That's why I need to launch authconfig with explicit ldap servers
>  > (and I don't want them to be declared in ldap_uri).
>  >
>
>
>  Why are you configuring pam_ldap if you're using SSSD? That doesn't
>  make any sense.
>
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.14 (GNU/Linux)
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >  iEYEARECAAYFAlJX9lkACgkQeiVVYja6o6MK+ACeKqoFBNgp85yorZ1TnP2R6+1c
> >  870An1EBiYZbfpowfFKTvkyaDY3H1xR4
> >  =mg52
> >  -----END PGP SIGNATURE----- 
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/11/2013 08:07 AM, Olivier wrote:
>  Hello Stephen,
>  
>  this is done : https://bugzilla.redhat.com/show_bug.cgi?id=1018189
>  
>  I have reported it as an authconfig bug, I think it might also be
>  something to be considered at sssd level : should'nt sssd use
>  "dns_discovery_domain" to look for ldap server rather than
>  "ldap_uri" if borth parameters are declared in sssd.conf ?
>   

No, because they're not directly related. You could be using DNS
discovery only for Kerberos (for example). The idea is that if you
have ldap_uri specified, you're doing it intentionally to override DNS.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJX7VAACgkQeiVVYja6o6Mw7QCdG/QZW/J+s3MS9UOyYo7A1sGH
> q1IAoIxlfr/0WOnQLdgYgx7maBKSnjWd
> =i0p+
> -----END PGP SIGNATURE-----

[Olivier]

Ah ! I see.

Thanks


2013/10/11 Stephen Gallagher <sgallagh(a)redhat.com&gt;

>  -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  On 10/11/2013 08:07 AM, Olivier wrote:
>  > Hello Stephen,
>  >
>  > this is done : https://bugzilla.redhat.com/show_bug.cgi?id=1018189
>  >
>  > I have reported it as an authconfig bug, I think it might also be
>  > something to be considered at sssd level : should'nt sssd use
>  > "dns_discovery_domain" to look for ldap server rather than
>  > "ldap_uri" if borth parameters are declared in sssd.conf ?
>  >
>
>
>  No, because they're not directly related. You could be using DNS
>  discovery only for Kerberos (for example). The idea is that if you
>  have ldap_uri specified, you're doing it intentionally to override DNS.
> >  -----BEGIN PGP SIGNATURE-----
> >  Version: GnuPG v1.4.14 (GNU/Linux)
> >  Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> >
> >  iEYEARECAAYFAlJX7VAACgkQeiVVYja6o6Mw7QCdG/QZW/J+s3MS9UOyYo7A1sGH
> >  q1IAoIxlfr/0WOnQLdgYgx7maBKSnjWd
> >  =i0p+
> >  -----END PGP SIGNATURE----- 
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>

[Michael Ströder]

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 still my concerns regarding the TLS hostname check is unanswered.

Ciao, Michael.

[Olivier]

> But still my concerns regarding the TLS hostname check is unanswered.
DNSSEC ?

Best

2013/9/26 Michael Ströder <michael(a)stroeder.com&gt;

>  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 still my concerns regarding the TLS hostname check is unanswered.
>
>  Ciao, Michael.
>
>
>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
>

[Michael Ströder]

Olivier wrote:
> > But still my concerns regarding the TLS hostname check is
> unanswered.
>  
>  DNSSEC ? 
I've expected this to be mentioned. But did you look closely into what's
needed to get the fat beast DNSSEC working?

Ciao, Michael.

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 09/25/2013 02:22 PM, Michael Ströder wrote:
>  Stephen Gallagher wrote:
> > On 09/25/2013 09:06 AM, Olivier wrote:
> >> if I may an additionnal question : would the sssd fallback 
> >> mecanism work with the DNS discovery ?
> > 
> >> Aka, if I'd configure this in the DNS :
> > 
> >> _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	10 0
> >> 389 ldap1.example.com <http://ldap1.example.com>;. 
> >> _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	20 0
> >> 389 ldap2.example.com <http://ldap2.example.com>;.
> > 
> >> will sssd fallback properly to ldap2 if ldap1 does not respond
> >> ?
> > 
> > Yes, and in fact this is the recommended mechanism for setting up
> > SSSD in your environment, since you need only to update the DNS
> > records and all of your clients will have access to a new set of
> > LDAP servers (i.e. if you provision additional ones and/or retire
> > others).
>  
>  Hmm, I really wonder why SRV RRs are recommended over having a
>  single service CNAME RR and maybe several A/AAAA RRs?
>  
>  Especially I'm concerned whether the TLS hostname check is
>  properley done in case of TLS connections (StartTLS ext.op or
>  LDAPS). Because a hostname check has to be performed against
>  *a-priori* knowledge of the client to fight against MITM attacks
>  with DNS spoofing.
>  
>  So if you're local configuration just knows "example.com" the
>  server cert MUST have a subject alt name with that domain name. I
>  doubt that LDAP clients really check this.
>   
Would you mind rephrasing this question? I'm not really sure I
understand. The expectation with the LDAP server is that it would have
an x.509 server certificate issued for its fully-qualified domain
name. In the example above, that would be ldap1.example.com and
ldap2.example.com.

If those referenced A records are also a load balancer pointing to
other machines behind it, then yes. ldap1-1.example.com and
ldap1-2.example.com would need their cert to have a subject alt name
with the FQDN ldap.example.com since that's the name they would
addressed by.

And yes, SSSD *does* check this carefully. Under the hood, we do the
following (to explain in possible unnecessary detail; I'm going to
gloss over the failover and assume that all servers are working).

1) Look up the SRV record.
2) Look up the A/AAAA record for the FQDN referenced in the SRV record
3) Open a socket to the first returned IP address
4) Hand off the file descriptor of this socket to the openldap client
libraries, specifying the URI to the libraries as
LDAP[s]://ldap1.example.com
5) The ldap client library will open the connection and request the
server certificate.
6) The ldap client library will validate the certificate first that
either the subject or subject alt name matches the URI we gave it and
then will verify that the server certificate is appropriately signed
by a trusted authority.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.14 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iEYEARECAAYFAlJEKA4ACgkQeiVVYja6o6N1eACff7WWl3ZsD3TwKsc2BKjEo6b9
> ViQAoJDzj5Dfi42SPx08LUwfljHyT8/D
> =6UnE
> -----END PGP SIGNATURE-----

[Michael Ströder]

Stephen Gallagher wrote:
>  On 09/25/2013 02:22 PM, Michael Ströder wrote:
> > Stephen Gallagher wrote:
> >> On 09/25/2013 09:06 AM, Olivier wrote:
> >>> if I may an additionnal question : would the sssd fallback
> >>> mecanism work with the DNS discovery ?
> >>
> >>> Aka, if I'd configure this in the DNS :
> >>
> >>> _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	10 0
> >>> 389 ldap1.example.com <http://ldap1.example.com>;.
> >>> _ldap._tcp.example.com <http://tcp.example.com>;.	IN	SRV	20 0
> >>> 389 ldap2.example.com <http://ldap2.example.com>;.
> >>
> >>> will sssd fallback properly to ldap2 if ldap1 does not respond
> >>> ?
> >>
> >> Yes, and in fact this is the recommended mechanism for setting up
> >> SSSD in your environment, since you need only to update the DNS
> >> records and all of your clients will have access to a new set of
> >> LDAP servers (i.e. if you provision additional ones and/or retire
> >> others).
>  
> > Hmm, I really wonder why SRV RRs are recommended over having a
> > single service CNAME RR and maybe several A/AAAA RRs?
>  
> > Especially I'm concerned whether the TLS hostname check is
> > properley done in case of TLS connections (StartTLS ext.op or
> > LDAPS). Because a hostname check has to be performed against
> > *a-priori* knowledge of the client to fight against MITM attacks
> > with DNS spoofing.
>  
> > So if you're local configuration just knows "example.com" the
> > server cert MUST have a subject alt name with that domain name. I
> > doubt that LDAP clients really check this.
>  
>  Would you mind rephrasing this question? I'm not really sure I
>  understand. The expectation with the LDAP server is that it would have
>  an x.509 server certificate issued for its fully-qualified domain
>  name. In the example above, that would be ldap1.example.com and
>  ldap2.example.com. 
I'd like to be more precise here:
No matter what the FQDN of the server at OS level is the client expects the
hostname it used for making the connection.

Example:
Client configuration contains ldap.example.com.
The FQDN of the LDAP server is srv1.example.com.
In DNS ldap.example.com is a CNAME pointing to ldapsrv1.example.com which in
turn has a A RR for the IP address of the service interface of
srv1.example.com where the LDAP server is listening.
=> the client simply has to check whether ldap.example.com is in the server
cert. This protects against DNS spoofing attacks (provided cert validation
etc. is done right).

>  And yes, SSSD *does* check this carefully. Under the hood, we do the
>  following (to explain in possible unnecessary detail; I'm going to
>  gloss over the failover and assume that all servers are working).
>  
>  1) Look up the SRV record. 
This could be spoofed.

>  2) Look up the A/AAAA record for the FQDN referenced in the SRV
> record
>  3) Open a socket to the first returned IP address
>  4) Hand off the file descriptor of this socket to the openldap client
>  libraries, specifying the URI to the libraries as
>  LDAP[s]://ldap1.example.com
>  5) The ldap client library will open the connection and request the
>  server certificate.
>  6) The ldap client library will validate the certificate first that
>  either the subject or subject alt name matches the URI we gave it and
>  then will verify that the server certificate is appropriately signed
>  by a trusted authority. 
The client should check two things:
1. The usual hostname check comparing a hostname derived from one of the SRV
RRs to protect against the spoofing of the CNAME/A lookup (CN or subjectAltName).
2. A service URL check, e.g. ldap:///dc=example,dc=com to protect against the
spoofing of the SRV lookup (only subjectAltName).

Unfortunately the LDAP part of RFC 6125 does not say something about this:

http://tools.ietf.org/html/rfc6125#appendix-B.3

Also the SRV-ID in RFC 6125 is not really suitable for SRV RRs in case of LDAP:

http://tools.ietf.org/html/rfc6125#section-6.5

Ciao, Michael.