[SSSD-users] 1.11.5 ddns failure on Ubuntu 14.04[SOLVED]

Jakub Hrozek jhrozek at redhat.com
Wed Jul 9 20:58:23 UTC 2014


On 25 Jun 2014, at 16:57, Simo Sorce <simo at 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 at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users



More information about the sssd-users mailing list