I installed another machine, using the same procedure as for the previous one; DNS entry is created, but dyndns updates fail exactly as for the first one: both machines discover the same active DNS server, to which try to send updated A records
(I have no access to the log, but asked my AD-admins colleges to look into).
sssd.conf : [nss] debug_level = 9 filter_groups = root filter_users = root,lightdm,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd
[sssd] debug_level = 6 domains =nat.domain.org config_file_version = 2 services = nss, pam
[domain/nat.domain.org] debug_level = 7 ad_domain = nat.domain.org krb5_realm = NAT.DOMAIN.ORG realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad auth_provider = ad access_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = False use_fully_qualified_names = True fallback_homedir = /home/%d/%u # dyndns_update = true
Best Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 20. juni 2014 17:42 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[SOLVED] (fwd)
On Fri, 2014-06-20 at 07:37 +0000, Longina Przybyszewska wrote:
The same happened to the keytab file. Here the right one, corresponding to the log file.
2 05/19/2014 10:36:55 SKYWALKER$@NAT.DOMAIN.ORG
Hi And the corresponding sssd.conf?
Anyway, sssd is sending the correct stuff to nsupdate for the forward rr but the log ends there, so assuming it fails for the reverse too.
Another good way of debugging it is to perform the update by hand using nsupdate -g Do you have access to the AD dns logs? HTH Steve
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Ok. 2 cases:
1. The first server is the server chosen automatically by service discovery - obviously doesn't answer
root@skywalker:/home-local/longinap# nsupdate -g -D setup_system() reset_system() user_interaction()
server nat-vdc0b.nat.domain.org
do_next_command()
realm NAT.DOMAIN.ORG
do_next_command()
update delete skywalker. in A
do_next_command() evaluate_update() update_addordelete()
update delete skywalker. in AAAA
do_next_command() evaluate_update() update_addordelete()
update add skywalker. 3600 in A 10.80.8.91
do_next_command() evaluate_update() update_addordelete()
send
do_next_command() start_update() recvsoa() ; Communication with 10.144.5.18#53 failed: timed out could not talk to specified name server
2. the server is the DNS server from the pool, I guess should work:
root@skywalker:/home-local/longinap# nsupdate -g -D setup_system() reset_system() user_interaction()
server 10.144.5.25
do_next_command()
realm NAT.DOMAIN.ORG
do_next_command()
update delete skywalker. in A
do_next_command() evaluate_update() update_addordelete()
update delete skywalker. in AAAA
do_next_command() evaluate_update() update_addordelete()
update add skywalker. 3600 in A 10.80.8.91
do_next_command() evaluate_update() update_addordelete()
send
do_next_command() start_update() recvsoa() About to create rcvmsg show_message() Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36935 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 3 ;; QUESTION SECTION: ;skywalker.
;; AUTHORITY SECTION: . 57087 IN NS b.root-servers.net. . 57087 IN NS h.root-servers.net. . 57087 IN NS j.root-servers.net. . 57087 IN NS a.root-servers.net. . 57087 IN NS l.root-servers.net. . 57087 IN NS c.root-servers.net. . 57087 IN NS m.root-servers.net. . 57087 IN NS f.root-servers.net. . 57087 IN NS d.root-servers.net. . 57087 IN NS g.root-servers.net. . 57087 IN NS e.root-servers.net. . 57087 IN NS i.root-servers.net. . 57087 IN NS k.root-servers.net.
;; ADDITIONAL SECTION: b.root-servers.net. 57087 IN A 192.228.79.201 b.root-servers.net. 57087 IN AAAA 2001:500:84::b h.root-servers.net. 57087 IN A 128.63.2.53
Out of recvsoa recvsoa() About to create rcvmsg show_message() Reply from SOA query: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49536 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 13, ADDITIONAL: 12 ;; QUESTION SECTION: ;. IN SOA
;; AUTHORITY SECTION: . 57087 IN NS h.root-servers.net. . 57087 IN NS j.root-servers.net. . 57087 IN NS a.root-servers.net. . 57087 IN NS l.root-servers.net. . 57087 IN NS c.root-servers.net. . 57087 IN NS m.root-servers.net. . 57087 IN NS f.root-servers.net. . 57087 IN NS d.root-servers.net. . 57087 IN NS g.root-servers.net. . 57087 IN NS e.root-servers.net. . 57087 IN NS i.root-servers.net. . 57087 IN NS k.root-servers.net. . 57087 IN NS b.root-servers.net.
;; ADDITIONAL SECTION: h.root-servers.net. 57087 IN A 128.63.2.53 h.root-servers.net. 57087 IN AAAA 2001:500:1::803f:235 j.root-servers.net. 57087 IN A 192.58.128.30 j.root-servers.net. 57087 IN AAAA 2001:503:c27::2:30 a.root-servers.net. 57087 IN A 198.41.0.4 a.root-servers.net. 57087 IN AAAA 2001:503:ba3e::2:30 l.root-servers.net. 61001 IN A 199.7.83.42 l.root-servers.net. 57087 IN AAAA 2001:500:3::42 c.root-servers.net. 57087 IN A 192.33.4.12 c.root-servers.net. 57087 IN AAAA 2001:500:2::c m.root-servers.net. 61001 IN A 202.12.27.33 m.root-servers.net. 57087 IN AAAA 2001:dc3::35
could not find enclosing zone root@skywalker:/home-local/longinap#
best Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 22. juni 2014 16:50 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]
On Sun, 2014-06-22 at 14:30 +0000, Longina Przybyszewska wrote:
(I have no access to the log
Ok, you don't need it. The cli output for nsupdate -g will tell us what's wrong. Just post that. Steve
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, 2014-06-23 at 09:09 +0000, Longina Przybyszewska wrote:
Ok. 2 cases:
- The first server is the server chosen automatically by service discovery - obviously doesn't answer.
Hi Narrow it down. Set the primary dns on your client to be a dns server which you know for certain is handling your ad domain. For now remove other dns entries and strip sssd of anything apart from ad.
/etc/hosts 127.0.0.1 catral.hh3.site catral localhost
/etc/resolv.conf search hh3.site nameserver 192.168.1.16
sssd.conf [sssd] services = nss, pam config_file_version = 2 domains = hh3.site [nss] [pam] [domain/hh3.site] id_provider = ad access_provider = ad auth_provider = ad ldap_id_mapping = false
e.g. here is an openSUSE client running 1.11.5 joined to the domain hh3.site. The DC at 192.168.1.16 is also running bind for this domain. A session on catral with a common error;)
catral:/home/steve # nsupdate -g
update delete catral.hh3.site. in A send
tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Ticket expired. catral:/home/steve # kinit -kt /etc/krb5.keytab CATRAL$ catral:/home/steve # nsupdate -g
update delete catral.hh3.site. in A send update add catral.hh3.site. 3600 in A 192.168.1.25 send quit
catral:/home/steve # nslookup catral Server: 192.168.1.16 Address: 192.168.1.16#53 Name: catral.hh3.site Address: 192.168.1.25
If you haven't got the dns exactly right, you may need some tweaks in sssd.conf to get you there: http://linuxcostablanca.blogspot.com.es/2014/05/sssd-autofs-with-ad-backend....
HTH Steve
My AD-admin affirms that the problem with Linux clients is - that they recognize AD/ldap server as DNS server; they should be able to recognize automatically the right DNS servers
Stripping sssd.conf doesn't help; Client still chooses DNS another server from pool of ldap/ad servers, with the same effect: non responding server for nsupdate
How can I force sssd to choose the right DNS server? There is 'dns_discovery_domain' option, but it means thet client configuration will differ per domain
Our AD structure is forest with trusted subdomains, and Global Catalog.
Best, Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 23. juni 2014 13:07 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]
On Mon, 2014-06-23 at 09:09 +0000, Longina Przybyszewska wrote:
Ok. 2 cases:
- The first server is the server chosen automatically by service discovery - obviously doesn't answer.
Hi Narrow it down. Set the primary dns on your client to be a dns server which you know for certain is handling your ad domain. For now remove other dns entries and strip sssd of anything apart from ad.
/etc/hosts 127.0.0.1 catral.hh3.site catral localhost
/etc/resolv.conf search hh3.site nameserver 192.168.1.16
sssd.conf [sssd] services = nss, pam config_file_version = 2 domains = hh3.site [nss] [pam] [domain/hh3.site] id_provider = ad access_provider = ad auth_provider = ad ldap_id_mapping = false
e.g. here is an openSUSE client running 1.11.5 joined to the domain hh3.site. The DC at 192.168.1.16 is also running bind for this domain. A session on catral with a common error;)
catral:/home/steve # nsupdate -g
update delete catral.hh3.site. in A send
tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Ticket expired. catral:/home/steve # kinit -kt /etc/krb5.keytab CATRAL$ catral:/home/steve # nsupdate -g
update delete catral.hh3.site. in A send update add catral.hh3.site. 3600 in A 192.168.1.25 send quit
catral:/home/steve # nslookup catral Server: 192.168.1.16 Address: 192.168.1.16#53 Name: catral.hh3.site Address: 192.168.1.25
If you haven't got the dns exactly right, you may need some tweaks in sssd.conf to get you there: http://linuxcostablanca.blogspot.com.es/2014/05/sssd-autofs-with-ad-backend....
HTH Steve
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
Hi again, I can see in log, that the client traverses all subdomains and tries to send dyndns updates to diverse DC's, without success. I have no krb5.conf - as I used realmd for joining AD - can it be the reason for troubles?
[nss] debug_level = 9 filter_groups = root filter_users = root,lightdm,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd
[sssd] debug_level = 6 domains =nat.domain.org config_file_version = 2 services = nss, pam
[domain/nat.domain.org] debug_level = 7 id_provider = ad auth_provider = ad access_provider = ad default_shell = /bin/bash ldap_id_mapping = False
/etc/hosts root@skywalker:/home-local/longinap# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 skywalker.nat.domain.org skywalker xxx.xxx. eta.nat.domain.org eta
best, Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Longina Przybyszewska Sent: 23. juni 2014 13:45 To: 'End-user discussions about the System Security Services Daemon' Subject: Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]
My AD-admin affirms that the problem with Linux clients is - that they recognize AD/ldap server as DNS server; they should be able to recognize automatically the right DNS servers
Stripping sssd.conf doesn't help; Client still chooses DNS another server from pool of ldap/ad servers, with the same effect: non responding server for nsupdate
How can I force sssd to choose the right DNS server? There is 'dns_discovery_domain' option, but it means thet client configuration will differ per domain
Our AD structure is forest with trusted subdomains, and Global Catalog.
Best, Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 23. juni 2014 13:07 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]
On Mon, 2014-06-23 at 09:09 +0000, Longina Przybyszewska wrote:
Ok. 2 cases:
- The first server is the server chosen automatically by service discovery - obviously doesn't answer.
Hi Narrow it down. Set the primary dns on your client to be a dns server which you know for certain is handling your ad domain. For now remove other dns entries and strip sssd of anything apart from ad.
/etc/hosts 127.0.0.1 catral.hh3.site catral localhost
/etc/resolv.conf search hh3.site nameserver 192.168.1.16
sssd.conf [sssd] services = nss, pam config_file_version = 2 domains = hh3.site [nss] [pam] [domain/hh3.site] id_provider = ad access_provider = ad auth_provider = ad ldap_id_mapping = false
e.g. here is an openSUSE client running 1.11.5 joined to the domain hh3.site. The DC at 192.168.1.16 is also running bind for this domain. A session on catral with a common error;)
catral:/home/steve # nsupdate -g
update delete catral.hh3.site. in A send
tkey query failed: GSSAPI error: Major = Unspecified GSS failure. Minor code may provide more information, Minor = Ticket expired. catral:/home/steve # kinit -kt /etc/krb5.keytab CATRAL$ catral:/home/steve # nsupdate -g
update delete catral.hh3.site. in A send update add catral.hh3.site. 3600 in A 192.168.1.25 send quit
catral:/home/steve # nslookup catral Server: 192.168.1.16 Address: 192.168.1.16#53 Name: catral.hh3.site Address: 192.168.1.25
If you haven't got the dns exactly right, you may need some tweaks in sssd.conf to get you there: http://linuxcostablanca.blogspot.com.es/2014/05/sssd-autofs-with-ad-backend....
HTH Steve
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Mon, 2014-06-23 at 12:28 +0000, Longina Przybyszewska wrote:
Hi again, I can see in log, that the client traverses all subdomains and tries to send dyndns updates to diverse DC's, without success. I have no krb5.conf - as I used realmd for joining AD - can it be the reason for troubles?
[nss] debug_level = 9 filter_groups = root filter_users = root,lightdm,ldap,named,avahi,haldaemon,dbus,radvd,tomcat,radiusd,news,mailman,nscd
[sssd] debug_level = 6 domains =nat.domain.org config_file_version = 2 services = nss, pam
[domain/nat.domain.org] debug_level = 7 id_provider = ad auth_provider = ad access_provider = ad default_shell = /bin/bash ldap_id_mapping = False
ad_server = any DC may help. Add this to /etc/hosts if the SRV lookups are failing.
/etc/hosts root@skywalker:/home-local/longinap# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 skywalker.nat.domain.org skywalker xxx.xxx. eta.nat.domain.org eta
If you used realmd you probably don't have the krb5 stuff installed. You could try:
[libdefaults] default_realm = NAT.DOMAIN.ORG dns_lookup_realm = false dns_lookup_kdc = true
BUT, all you really need is the IP of a dns server in the domain. The one the windows clients use will do fine. Can you get at Control Panel on a windows client and find out what it is?
Steve
If you used realmd you probably don't have the krb5 stuff installed. You could try:
[libdefaults] default_realm = NAT.DOMAIN.ORG dns_lookup_realm = false dns_lookup_kdc = true
BUT, all you really need is the IP of a dns server in the domain. The one the windows clients use will do fine. Can you get at Control Panel on a windows client and find out what it is?
I have got 2 IP for DNS servers for dyndns updates from AD-admin - but I don't know where put them in config file.
I tried option: ad_server =xx.xx.xx.xx, yy.yy.yy.yy
doesn't help.
/etc/resolv.conf is overwritten af: root@skywalker:/home-local/longinap# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1 --------- root@skywalker:/home-local/longinap# cat /etc/hosts 127.0.0.1 localhost 127.0.1.1 skywalker.nat.c.sdu.dk skywalker 10.144.4.254 eta.nat.c.sdu.dk eta
Best Longina
On Mon, 2014-06-23 at 13:52 +0000, Longina Przybyszewska wrote:
/etc/resolv.conf is overwritten af: root@skywalker:/home-local/longinap# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1
OK. Now we're getting somewhere. That's not going to get you to an AD dns server.
Set the dns to the same server which the windows boxes use. Remove dnsmasq if it's up and set /etc/nsswitch.conf to: hosts: files dns
I'm guessing Ubuntu. So look here: http://linuxcostablanca.blogspot.com.es/2014/05/dns-good-enough-for-kerberos... If not, do it the old way in: /etc/network/interfaces
Smile please:) Steve
Hi again, thanks a lot! What about service discovery mechanism in SSSD? I could expect, that the AD services advertise themselves and for SSSD this is the base for finding the right way to establish connection to the DC/DNS or whatever. In our Enterprise we have AD DNS and split DNS. Clients contact split DNS for resolve addresser - so I can not configure client to refer directly to AD DNS. My client(with SSSD) has to find out who runs AD DNS for dyndns updates, and by now it contacts the wrong server. Does it use information from resolvconf?
How can I manually find out which serveres advertise dyndns service?
Best, Longina
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of steve Sent: 23. juni 2014 16:06 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]
On Mon, 2014-06-23 at 13:52 +0000, Longina Przybyszewska wrote:
/etc/resolv.conf is overwritten af: root@skywalker:/home-local/longinap# cat /etc/resolv.conf # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 127.0.1.1
OK. Now we're getting somewhere. That's not going to get you to an AD dns server.
Set the dns to the same server which the windows boxes use. Remove dnsmasq if it's up and set /etc/nsswitch.conf to: hosts: files dns
I'm guessing Ubuntu. So look here: http://linuxcostablanca.blogspot.com.es/2014/05/dns-good-enough-for-kerberos... If not, do it the old way in: /etc/network/interfaces
Smile please:) Steve
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Tue, 2014-06-24 at 09:02 +0000, Longina Przybyszewska wrote:
My client(with SSSD) has to find out who runs AD DNS for dyndns updates, and by now it contacts the wrong server.
I dunno if that's possible. I know it finds ldap and kerberos OK because it follows SRV rrs. Does AD use SRVs for DNS discovery? Even on windows you have to point to primary DNS at something.
Does it use information from resolvconf?
Yes.
How can I manually find out which serveres advertise dyndns service?
Repeat:
Set the dns to the same server which the windows boxes use.
Your AD admin knows the answer. Maybe you need to buy him a beer? Cheers, Steve
It seems to work - !"#¤%&! Combination of -/etc/krb5.conf (though used realm for AD join) - /etc/resolv.conf ( with the right dns sserver = tweak /etc/dhcpd/dhclient.conf + /etc/NetworkManager.conf) -/etc/hostname (fqdn) -/etc/hosts (off with 127.0.1.1 fqdn shortname --> 127.0.0.1 fqdn shortname localhost)
Without a beer ;), Thanks for help :)
Best Longina
On 24 Jun 2014, at 13:43, steve steve@steve-ss.com wrote:
On Tue, 2014-06-24 at 09:02 +0000, Longina Przybyszewska wrote:
My client(with SSSD) has to find out who runs AD DNS for dyndns updates, and by now it contacts the wrong server.
I dunno if that's possible. I know it finds ldap and kerberos OK because it follows SRV rrs. Does AD use SRVs for DNS discovery? Even on windows you have to point to primary DNS at something.
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was the difference between the right server and the wrong server in your setup.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
Does it use information from resolvconf?
Yes.
How can I manually find out which serveres advertise dyndns service?
Repeat:
Set the dns to the same server which the windows boxes use.
Your AD admin knows the answer. Maybe you need to buy him a beer? Cheers, Steve
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supply data for update record for nsupdate, right?
---this doesn't work--- server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete skywalker. in A send update delete skywalker. in AAAA send update add skywalker. 3600 in A 10.80.8.91 send ----
---- works, after hokus-pokus with /etc/{hosts,hostname,dhclient}--- server nat-vdc0b.nat.c.sdu.dk realm NAT.C.SDU.DK update delete skywalker.nat.domain.org in A send update delete skywalker.nat.domain.org in AAAA send update add skywalker.nat.domain.org 3600 in A 10.80.8.91 send ----
How SSSD resolves domainname for machine for supplying to nsupdate record? It could be nice to be sure if 'dnsdomainname' returned domainname, this one was used for 'nsupdate'. In my initial config the following commands returned correctly: hostname -s hostname -f dnsdomainname ...but the nsupdate record was wrong. It was confusing...
PTR dyndns still doesn’t work :
---- doesn’t work--- server server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete 91.8.80.10.in-addr.arpa. in PTR update add 91.8.80.10-in-addr.arpa. 3600 in PTR skywalker.nat.c.sdu.dk. send ---
Servers nat-vdc0{a,b,c} are LDAP servers for nat.domain.org not DNS servers.
Best Longina
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
---this doesn't work--- server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete skywalker. in A send update delete skywalker. in AAAA send update add skywalker. 3600 in A 10.80.8.91 send ----
---- works, after hokus-pokus with /etc/{hosts,hostname,dhclient}---
server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete skywalker.nat.domain.org in A send update delete skywalker.nat.domain.org in AAAA send update add skywalker.nat.domain.org 3600 in A 10.80.8.91 send ----
How SSSD resolves domainname for machine for supplying to nsupdate record? It could be nice to be sure if 'dnsdomainname' returned domainname, this one was used for 'nsupdate'. In my initial config the following commands returned correctly: hostname -s hostname -f dnsdomainname ...but the nsupdate record was wrong. It was confusing...
PTR dyndns still doesn’t work :
---- doesn’t work--- server server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete 91.8.80.10.in-addr.arpa. in PTR update add 91.8.80.10-in-addr.arpa. 3600 in PTR skywalker.nat.domain.org. send ---
Servers nat-vdc0{a,b,c} are LDAP servers for nat.domain.org not DNS servers.
Best Longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
Simo.
---this doesn't work--- server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete skywalker. in A send update delete skywalker. in AAAA send update add skywalker. 3600 in A 10.80.8.91 send
---- works, after hokus-pokus with /etc/{hosts,hostname,dhclient}---
server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete skywalker.nat.domain.org in A send update delete skywalker.nat.domain.org in AAAA send update add skywalker.nat.domain.org 3600 in A 10.80.8.91 send
How SSSD resolves domainname for machine for supplying to nsupdate record? It could be nice to be sure if 'dnsdomainname' returned domainname, this one was used for 'nsupdate'. In my initial config the following commands returned correctly: hostname -s hostname -f dnsdomainname ...but the nsupdate record was wrong. It was confusing...
PTR dyndns still doesn’t work :
---- doesn’t work--- server server nat-vdc0b.nat.domain.org realm NAT.DOMAIN.ORG update delete 91.8.80.10.in-addr.arpa. in PTR update add 91.8.80.10-in-addr.arpa. 3600 in PTR skywalker.nat.domain.org. send
Servers nat-vdc0{a,b,c} are LDAP servers for nat.domain.org not DNS servers.
Best Longina
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
But if we already know the answer for which DNS server to use, surely sssd should not override what has been set locally at /etc/resolv.conf should it? If you must pass the server name then choose the one which has already been given, not the one which you've found via SRVs. Just our €0,02 Steve
On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote:
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
But if we already know the answer for which DNS server to use, surely sssd should not override what has been set locally at /etc/resolv.conf should it? If you must pass the server name then choose the one which has already been given, not the one which you've found via SRVs. Just our €0,02 Steve
You're describing something different than what Simo was describing.
So you're proposing that the 'server' directive is a server from /etc/resolv.conf, not whatever server we are talking to?
If that's the case, then it wouldn't work. Quite often, the server in resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would be running on the client machine. Or the AD server could be resolved with the help of /etc/hosts..
On Wed, 2014-06-25 at 16:22 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote:
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
But if we already know the answer for which DNS server to use, surely sssd should not override what has been set locally at /etc/resolv.conf should it? If you must pass the server name then choose the one which has already been given, not the one which you've found via SRVs. Just our €0,02 Steve
You're describing something different than what Simo was describing.
Quite possible, but I'm trying to stick to the thread and trying to help the OP by describing her observations. IOW, don't send the wrong server to nsupdate. If dns is working correctly, you do not need to specify the server anyway.
So you're proposing that the 'server' directive is a server from /etc/resolv.conf, not whatever server we are talking to?
If that's the case, then it wouldn't work. Quite often, the server in resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would be running on the client machine. Or the AD server could be resolved with the help of /etc/hosts..
That would never be the case as you would not be able to join the domain. The primary DNS _must_ point at the server responsible for the zone. Your method with realmd may get around that but unless you get the dns perfect you can forget about joining AD.
If as you say, you wish sssd to do as little as possible, then don't overwrite what dns does anyway by overriding the server which is sent to nsupdate. It is then up to the admin to sort out the dns when it doesn't work. Thanks, Steve
On Wed, Jun 25, 2014 at 04:59:28PM +0200, steve wrote:
On Wed, 2014-06-25 at 16:22 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote:
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
>By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
>In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
But if we already know the answer for which DNS server to use, surely sssd should not override what has been set locally at /etc/resolv.conf should it? If you must pass the server name then choose the one which has already been given, not the one which you've found via SRVs. Just our €0,02 Steve
You're describing something different than what Simo was describing.
Quite possible, but I'm trying to stick to the thread and trying to help the OP by describing her observations. IOW, don't send the wrong server to nsupdate.
Sorry, I didn't mean to offend you, I'm really glad you're helping us debug the problem, it's a huge help.
If dns is working correctly, you do not need to specify the server anyway.
Right.
So you're proposing that the 'server' directive is a server from /etc/resolv.conf, not whatever server we are talking to?
If that's the case, then it wouldn't work. Quite often, the server in resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would be running on the client machine. Or the AD server could be resolved with the help of /etc/hosts..
That would never be the case as you would not be able to join the domain. The primary DNS _must_ point at the server responsible for the zone.
Yes, but the local DNS server can just point to the right servers in its configuration, in other words redirect to the AD DC. So SRV records realmd uses would still be valid, but the address of the resolver in resolv.conf wouldn't be usable for dyndns purposes.
Your method with realmd may get around that but unless you get the dns perfect you can forget about joining AD.
If as you say, you wish sssd to do as little as possible, then don't overwrite what dns does anyway by overriding the server which is sent to nsupdate. It is then up to the admin to sort out the dns when it doesn't work.
I agree with this completely. I need to run some tests and re-read the code more carefully later to verify if we're indeed using the server always (which would be a bug) or just as a fallback (which would be OK and could be improved even more with the option Simo suggested).
Thanks, Steve
Thanks again for helping us on this list!
On Thu, 2014-06-26 at 13:52 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 04:59:28PM +0200, steve wrote:
On Wed, 2014-06-25 at 16:22 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote:
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote: > With correct domain ;)... > > >By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup. > > In our case, DNS server is not LDAP - it is separate win DNS serer. > There is also split DNS server resolving all in/out requests from intern clients. > This one is known for resolver on all clients, but can't be used for dyndns updates. > > >In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right.. > > > But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
But if we already know the answer for which DNS server to use, surely sssd should not override what has been set locally at /etc/resolv.conf should it? If you must pass the server name then choose the one which has already been given, not the one which you've found via SRVs. Just our €0,02 Steve
You're describing something different than what Simo was describing.
Quite possible, but I'm trying to stick to the thread and trying to help the OP by describing her observations. IOW, don't send the wrong server to nsupdate.
Sorry, I didn't mean to offend you, I'm really glad you're helping us debug the problem, it's a huge help.
If dns is working correctly, you do not need to specify the server anyway.
Right.
So you're proposing that the 'server' directive is a server from /etc/resolv.conf, not whatever server we are talking to?
If that's the case, then it wouldn't work. Quite often, the server in resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would be running on the client machine. Or the AD server could be resolved with the help of /etc/hosts..
That would never be the case as you would not be able to join the domain. The primary DNS _must_ point at the server responsible for the zone.
Yes, but the local DNS server can just point to the right servers in its configuration, in other words redirect to the AD DC. So SRV records realmd uses would still be valid, but the address of the resolver in resolv.conf wouldn't be usable for dyndns purposes.
Your method with realmd may get around that but unless you get the dns perfect you can forget about joining AD.
If as you say, you wish sssd to do as little as possible, then don't overwrite what dns does anyway by overriding the server which is sent to nsupdate. It is then up to the admin to sort out the dns when it doesn't work.
I agree with this completely. I need to run some tests and re-read the code more carefully later to verify if we're indeed using the server always (which would be a bug) or just as a fallback (which would be OK and could be improved even more with the option Simo suggested).
Thanks, Steve
Thanks again for helping us on this list!
A pleasure. It's very easy for coders to forget the people who actually use their tools. Real domains with real sssd.conf files exist with real people using them. As admins we have to pass on these messages to our superiors and 'translate' them into something they can understand. It gets worse when you are dealing with people who also ask you how they can get a capital letter on the keyboard because when the press a key with a capital letter on it, it comes out lowercase (sic). As you have a users and a developers list, it would be great if you could come some way to explaining and evaluating our suggestions on the former. Your comments here have helped enormously. Cheers, Steve
>
Yes, but the local DNS server can just point to the right servers in its configuration, in other words redirect to the AD DC. So SRV records realmd uses would still be valid, but the address of the resolver in resolv.conf wouldn't be usable for dyndns purposes.
Your method with realmd may get around that but unless you get the dns perfect you can forget about joining AD.
If as you say, you wish sssd to do as little as possible, then don't overwrite what dns does anyway by overriding the server which is sent to nsupdate. It is then up to the admin to sort out the dns when it doesn't work.
I agree with this completely. I need to run some tests and re-read the code more carefully later to verify if we're indeed using the server always (which would be a bug) or just as a fallback (which would be OK and could be improved even more with the option Simo suggested).
It seems that it is fallback. If nsupdate can figure out the right fqdn in the update record, it works for realm[..].
Before, for some reason (still not obvious for me, following realmd and auto-created sssd.conf it didn't work), nsupdate send short name, then subsequent dyndns updates fallback to the DC server[..], not DNS server.
--- [nsupdate_msg_create_common] (0x0200): Creating update message for realm [NAT.C.SITE.ORG]. (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- realm NAT.C.SITE.ORG update delete skywalker.nat.c.site.org. in A send update delete skywalker.nat.c.site.org. in AAAA send update add skywalker.nat.c.site.org. 3600 in A 10.80.8.91 send (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_fwd_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2575] (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2575] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_done] (0x0200): nsupdate child status: 0
(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm [NAT.C.SITE.ORG]. (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- realm NAT.C.SITE.ORG update add 91.8.80.10.in-addr.arpa. 3600 in PTR skywalker.nat.c.site.org. send (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2591] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2591] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_process_result] (0x2000): Trace: sh[0x1568d30], connected[1], ops[(nil)], ldap[0x156aac0] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_args] (0x0200): (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_process_result] (0x2000): nsupdate auth type: GSS-TSIG Trace: ldap_result found nothing! (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.sdu.dk]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158229]: Dynamic DNS update timed out
.....
(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_dyndns_update_ptr_done] (0x0080): nsupdate failed, retrying with server name (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_msg_create_common] (0x0200): Creating update message for server [nat-vdc0b.nat.c.site.org] and realm [NAT.C.SITE.ORG] .(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- server nat-vdc0b.nat.c.site.org realm NAT.C.SITE.ORG update add 91.8.80.10.in-addr.arpa. 3600 in PTR skywalker.nat.c.site.org. send (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2597] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2597] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_args] (0x0200): nsupdate auth type: GSS-TSIG (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_dispatch] (0x4000): dbus conn: 0x1514a40 (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_timeout] (0x0020): Timeout reached for dynamic DNS update (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158229]: Dynamic DNS update timed out (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158229]: Dynamic DNS update timed out
---
---
Our DNS structure is combination of win DNS and Infoblox DNS (DHCP & split DNS for intern and extern addresser).
Win DNS servers (site-vdc0{g,f}.c.site.org) are responsible for top domain c.site.org, and subdomains {nat,tek..]c.site.org;
Infoblox DNS (ins.site.org) is responsible for all reverse zones plus some more (forward zones, external addresses etc.) - this is the one, which is known for resolver on all clients(my client too;). It turns out that in our case , Infoblox-reverse-DNS additionally, doesn't support Kerberos for updates.(!)
Best Longina
_______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On 26 Jun 2014, at 16:19, Longina Przybyszewska longina@sdu.dk wrote:
>>
Yes, but the local DNS server can just point to the right servers in its configuration, in other words redirect to the AD DC. So SRV records realmd uses would still be valid, but the address of the resolver in resolv.conf wouldn't be usable for dyndns purposes.
Your method with realmd may get around that but unless you get the dns perfect you can forget about joining AD.
If as you say, you wish sssd to do as little as possible, then don't overwrite what dns does anyway by overriding the server which is sent to nsupdate. It is then up to the admin to sort out the dns when it doesn't work.
I agree with this completely. I need to run some tests and re-read the code more carefully later to verify if we're indeed using the server always (which would be a bug) or just as a fallback (which would be OK and could be improved even more with the option Simo suggested).
It seems that it is fallback. If nsupdate can figure out the right fqdn in the update record, it works for realm[..].
Before, for some reason (still not obvious for me, following realmd and auto-created sssd.conf it didn't work), nsupdate send short name, then subsequent dyndns updates fallback to the DC server[..], not DNS server.
Hi Longina,
I’ve sent a patch to the sssd-devel list that adds a new option for sssd.conf which lets you specify the DNS server to use: https://lists.fedorahosted.org/pipermail/sssd-devel/2014-July/020586.html
Are you OK testing the patch yourself or would you prefer if we help you prepare some test build? We can do any Fedora/RHEL version and we also have some (limited) Debian experience..
Thank you very much for the patience while we debugged the issue and prepared a patch.
[nsupdate_msg_create_common] (0x0200): Creating update message for realm [NAT.C.SITE.ORG]. (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_fwd_msg] (0x0400): -- Begin nsupdate message -- realm NAT.C.SITE.ORG update delete skywalker.nat.c.site.org. in A send update delete skywalker.nat.c.site.org. in AAAA send update add skywalker.nat.c.site.org. 3600 in A 10.80.8.91 send (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_fwd_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2575] (Thu Jun 26 10:49:57 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2575] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_done] (0x0200): nsupdate child status: 0
(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_msg_create_common] (0x0200): Creating update message for realm [NAT.C.SITE.ORG]. (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- realm NAT.C.SITE.ORG update add 91.8.80.10.in-addr.arpa. 3600 in PTR skywalker.nat.c.site.org. send (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2591] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2591] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_process_result] (0x2000): Trace: sh[0x1568d30], connected[1], ops[(nil)], ldap[0x156aac0] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_args] (0x0200): (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_process_result] (0x2000): nsupdate auth type: GSS-TSIG Trace: ldap_result found nothing! (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.sdu.dk]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.sdu.dk]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158229]: Dynamic DNS update timed out
.....
(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_handler] (0x0040): Dynamic DNS child failed with status [256] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158228]: Dynamic DNS update failed (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [sdap_dyndns_update_ptr_done] (0x0080): nsupdate failed, retrying with server name (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_msg_create_common] (0x0200): Creating update message for server [nat-vdc0b.nat.c.site.org] and realm [NAT.C.SITE.ORG] .(Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- Begin nsupdate message -- server nat-vdc0b.nat.c.site.org realm NAT.C.SITE.ORG update add 91.8.80.10.in-addr.arpa. 3600 in PTR skywalker.nat.c.site.org. send (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_create_ptr_msg] (0x0400): -- End nsupdate message -- (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [2597] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [child_handler_setup] (0x2000): Signal handler set up for pid [2597] (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [write_pipe_handler] (0x0400): All data has been sent! (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_stdin_done] (0x1000): Sending nsupdate data complete (Thu Jun 26 10:50:03 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_args] (0x0200): nsupdate auth type: GSS-TSIG (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_dispatch] (0x4000): dbus conn: 0x1514a40 (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_dispatch] (0x4000): Dispatching. (Thu Jun 26 10:50:11 2014) [sssd[be[nat.c.site.org]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [nsupdate_child_timeout] (0x0020): Timeout reached for dynamic DNS update (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [be_nsupdate_done] (0x0040): nsupdate child execution failed [1432158229]: Dynamic DNS update timed out (Thu Jun 26 10:50:18 2014) [sssd[be[nat.c.site.org]]] [ad_dyndns_nsupdate_done] (0x0040): Updating DNS entry failed [1432158229]: Dynamic DNS update timed out
Our DNS structure is combination of win DNS and Infoblox DNS (DHCP & split DNS for intern and extern addresser).
Win DNS servers (site-vdc0{g,f}.c.site.org) are responsible for top domain c.site.org, and subdomains {nat,tek..]c.site.org;
Infoblox DNS (ins.site.org) is responsible for all reverse zones plus some more (forward zones, external addresses etc.) - this is the one, which is known for resolver on all clients(my client too;). It turns out that in our case , Infoblox-reverse-DNS additionally, doesn't support Kerberos for updates.(!)
Best Longina
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 2014-06-25 at 16:22 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote:
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
But if we already know the answer for which DNS server to use, surely sssd should not override what has been set locally at /etc/resolv.conf should it? If you must pass the server name then choose the one which has already been given, not the one which you've found via SRVs. Just our €0,02 Steve
You're describing something different than what Simo was describing.
So you're proposing that the 'server' directive is a server from /etc/resolv.conf, not whatever server we are talking to?
If that's the case, then it wouldn't work. Quite often, the server in resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would be running on the client machine. Or the AD server could be resolved with the help of /etc/hosts..
Correct, however the way the AD code uises the server names makes little sense. It uses the name used to connect to the LDAP server. Although this is generally a Domain Controller, it is not necessarily a DNS server (can be even a RODC). So if we need a fallback that should be an option specified in sssd.conf: something like: fallback_dns_master or similar. Deriving the DNS server from the LDAP name will be wrong more times than it is right in large environments.
Simo.
On Wed, Jun 25, 2014 at 11:00:47AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 16:22 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 04:07:12PM +0200, steve wrote:
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
>By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
>In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
But if we already know the answer for which DNS server to use, surely sssd should not override what has been set locally at /etc/resolv.conf should it? If you must pass the server name then choose the one which has already been given, not the one which you've found via SRVs. Just our €0,02 Steve
You're describing something different than what Simo was describing.
So you're proposing that the 'server' directive is a server from /etc/resolv.conf, not whatever server we are talking to?
If that's the case, then it wouldn't work. Quite often, the server in resolv.conf would be just 127.0.0.1 and a local dnsmasq or similar would be running on the client machine. Or the AD server could be resolved with the help of /etc/hosts..
Correct, however the way the AD code uises the server names makes little sense. It uses the name used to connect to the LDAP server. Although this is generally a Domain Controller, it is not necessarily a DNS server (can be even a RODC). So if we need a fallback that should be an option specified in sssd.conf: something like: fallback_dns_master or similar.
Yes, I agree with this, a new option seems like the only way. I will open a ticket.
Deriving the DNS server from the LDAP name will be wrong more times than it is right in large environments.
OK, perhaps, I guess your experience here is better than mine and the fact we're debugging the problem at all proves there /is/ a problem.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
As far as I can read the AD code always put the server there.
Down below the pure nsupdate code can cope with the server name missing, but the AD code doesn't, unless I am missing something.
Simo.
On 25 Jun 2014, at 16:57, Simo Sorce simo@redhat.com wrote:
On Wed, 2014-06-25 at 15:43 +0200, Jakub Hrozek wrote:
On Wed, Jun 25, 2014 at 09:34:25AM -0400, Simo Sorce wrote:
On Wed, 2014-06-25 at 09:30 +0000, Longina Przybyszewska wrote:
With correct domain ;)...
By default, we contact the server we establish the LDAP connection with. I’m sorry, I got a bit lost in the thread — what was >the difference between the right server and the wrong server in your setup.
In our case, DNS server is not LDAP - it is separate win DNS serer. There is also split DNS server resolving all in/out requests from intern clients. This one is known for resolver on all clients, but can't be used for dyndns updates.
In general, SSSD tries to do as little as possible and we try to let nsupdate do its job right..
But sssd supplies data for update record for nsupdate, right?
Please open a bug against sssd.
Please don't (yet).
For some reason the server name is being forcibly served top nsupdate and that shouldn't be the case, passing a "server" option should be only a fallback case.
It is only a fallback, the way I read the code. I haven't seen the full domain logs, so I can't tell if the sssd falls back to trying the server or tries the server right away (which would be a bug).
Nsupdate should be let the ability to discover the correct server by querying the DNS and picking the available authoritative server.
Feel free to quote the above ion the ticket. It is definitely a bug in sssd.
No, it's not.
As far as I can read the AD code always put the server there.
Down below the pure nsupdate code can cope with the server name missing, but the AD code doesn't, unless I am missing something.
The hostname /is/ passed from the AD code to the SDAP code unconditionally but not used for the first pass. If the first pass fails, then SSSD retries using the host name.
I implemented the suggestion you had with the new option, I think that’s the only way to solve the problem our users were having.
Simo.
-- Simo Sorce * Red Hat, Inc * New York
sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Wed, 2014-06-25 at 08:53 +0000, Longina Przybyszewska wrote:
How SSSD resolves domainname for machine for supplying to nsupdate record?
sssd doesn't do anything. nsupdate sends the dns update calls to whatever you have put in /etc/resolv.conf
On Mon, 2014-06-23 at 11:45 +0000, Longina Przybyszewska wrote:
My AD-admin affirms that the problem with Linux clients is - that they recognize AD/ldap server as DNS server.
Surely she can give you the IP of a suitable server _somewhere_ in the forest!
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Longina Przybyszewska -
Simo Sorce -
steve