Dynamic DNS updates in SSSD

SSSD supports dynamic DNS (DDNS) and utilizes nsupdate tool for this purpose. To enable/disable DDNS dyndns_update domain option is used.

When DDNS was enabled, by default the address of LDAP connection was used for the DNS updates. This behaviour has changed in the recent SSSD version. Now all (DNS valid) IPv4 and IPv6 addresses of the network interface (NIC) that is used for LDAP connection are used. This change was introduced mostly to handle use cases when full stack addresses of the client were deleted from the DNS server by the client DNS updates and only a single address (address of LDAP connection) was inserted.

Simple example of DDNS in SSSD:
• Network interfaces on IPA client (husker.example.test):

  ens9:
  inet 192.0.2.11/24 scope global
  inet6 2001:DB8::11/96 scope global
  inet6 fe80::5054:ff:fe8a:4999/64 scope link
  
  eth1:
  inet 198.51.100.11/24 scope global
  inet 198.51.100.12/24 scope global secondary eth1
  inet6 2001:DB8:1::11/96 scope global
  inet6 2001:DB8:1::12/96 scope global
  inet6 fe80::5054:ff:fe2d:90b/64 scope link
  

• Configure and restart SSSD

  husker # grep dyndns_update /etc/sssd/sssd.conf
  dyndns_update = True
  husker # sudo systemctl restart sssd
  

• Query address of IPA client (husker) on IPA server:

  ipa-server $ dig A husker.example.test +short
  192.0.2.11
  ipa-server $ dig AAAA husker.example.test +short
  2001:DB8::11
  

To handle use-cases when IPs from more than one NIC should be used, the domain option dyndns_iface was updated to accept not just one name of interface but also to accept a comma separated list of interface names. Also a special value * was introduced to imply that all host interfaces should be considered.

Usage of dyndns_iface‘s special value
• Use all NICs on husher

  husker # grep dyndns_iface /etc/sssd/sssd.conf
  dyndns_iface = *
  husker # sudo systemctl restart sssd
  

• Query addresses of IPA client (husker):

  ipa-server $ dig A  husker.example.test +short
  192.0.2.11
  198.51.100.11
  198.51.100.12
  
  ipa-server $ dig AAAA  husker.example.test +short
  2001:DB8::11
  2001:DB8:1::11
  2001:DB8:1::12
  

In previous paragraphs the term DNS valid address was mentioned. Addresses that are multicast, loop-back, link-local and broadcast are not usable for DNS, and thus are ignored by SSSD. This kind of events are logged in the SSSD domain log file if debug_level is equal or above SSSDBG_TRACE_LIBS (7).

husker $ grep 'check_ipv[46]_addr' sssd_ipa.work.log
[check_ipv4_addr] (0x0200): Loopback IPv4 address 127.0.0.1
[check_ipv6_addr] (0x0200): Loopback IPv6 address ::1
[check_ipv6_addr] (0x0200): Link local IPv6 address fe80::5054:ff:fe2d:90b

Hints for testing DDNS

• Nsupdate tool can be run directly from command line.

  nsupdate -o msg

  Where msg is a file containing the message used for the DNS update and switch -o makes nsupdate to use same kerberos credentials as SSSD. Message that SSSD uses for update is logged in the domain log file (debug_level option have to be at least equal to SSSDBG_TRACE_FUNC (6)). An example of the relevant part of log follows:

  -- Begin nsupdate message --
  realm EXAMPLE.TEST
  update delete husker.example.test. in A
  send
  update delete husker.example.test. in AAAA
  send
  update add husker.example.test. 1200 in AAAA 2001:DB8::11
  update add husker.example.test. 1200 in AAAA 2001:DB8:1::11
  update add husker.example.test. 1200 in AAAA 2001:DB8:1::12
  update add husker.example.test. 1200 in A 192.0.2.11
  update add husker.example.test. 1200 in A 198.51.100.11
  update add husker.example.test. 1200 in A 198.51.100.12
  send
  -- End nsupdate message --
  

• Check that appropriate domain zone is created on server

  ipa-server $ ipa dnszone-show example.test.
  Zone name: example.test.
  ... 
  

• Dynamic update is enabled on server

• Check bind update policy on ipa server.

  For debugging purposes only you might add rule "grant * wildcard *;"

Advertisement

Authenticate against cache in SSSD

What is the problem?

While querying information about users, groups, etc. via commands getent and id, which are internally calling NSS responder, is already optimized by usage of SSSD internal cache, on the contrary, authentication was always performed against server. Authentication against the network many times can cause an excessive application latency. Especially in environments with tens of thousands of users the login process may become inappropriately long when servers are running under high workload (e.g. during classes, when many users log in simultaneously). To handle such situations SSSD now supports cache authentication instead of authenticating directly against network server every time.

Solution

To address this problem new option cached_auth_timeout was introduced. This option specifies time in seconds since last successful on-line authentication for which the user will be authenticated using cached credentials while SSSD is in the on-line mode. By default cached_auth_timeout is set to 0 which implies that this feature is disabled.
In plain English it means that if cached_auth_timeout=900, then after successful on-line authentication all subsequent authentication attempts for next 15 minutes will be served from cache (at least all succesfull attempts; see special cases for details).

Setting the feature

Setting cached authentication is quite easy – just add cached_auth_timeout to the domain section and check that cache_credentials=true is also set in the domain section. Then restart SSSD and the feature should be working.

Example of configuration

[domain/domain.dev]
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = domain.dev
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = client.domain.dev
chpass_provider = ipa
dyndns_update = True
ipa_server = ipa.domain.dev
ldap_tls_cacert = /etc/ipa/ca.crt
realmd_tags = manages-system
default_shell = /bin/bash
use_fully_qualified_names = True
fallback_homedir = /home/%d/%u
cached_auth_timeout = 150

[sssd]
services = nss, sudo, pam, ssh
config_file_version = 2

domains = domain.dev
[nss]
homedir_substring = /home

[pam]
# you might consider to uncomment this option to see more verbose output while authenticating
#pam_verbosity = 2

[sudo]

[autofs]

[ssh]

[pac]

[ifp]

Special cases

There are a few special cases I would like to briefly describe.

Password got changed locally

In this case subsequent login attempt is processed on-line and the new password is accepted while the old one is denied.

Password got change directly on server or via other client then SSSD

The new password is accepted and that logs inform that cached authentication failed and on-line authentication had to be performed (please note that old password would be accepted as the SSSD client has no knowledge that it was changed).

Entered password does not match the cached one

In this case on-line authentication is performed because it cannot be determined whether there was a typo in password or password was changed directly on server. Also checking on-line is a protection against potential password guessing attacks.

SSSD is in off-line mode

If SSSD is in off-line mode, then this feature is not used and SSSD behaves as usual.

Further reading

• SSSD manual pages
• Design page

Hello world!

Hello,

My name is Pavel Reichl and I’m a software engineer at Red Hat. I’m a member of the identity management team. My main work focus is SSSD.

I hope that this blog will provide me a nice way to share information about some of the new features of SSSD.

Enjoy!