[SSSD-users] sssd.conf, authconfig and ldap_uri

Olivier ldap at guillard.nom.fr
Thu Oct 10 14:39:15 UTC 2013


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 at redhat.com>

> 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20131010/037ceaca/attachment.html>


More information about the sssd-users mailing list