On Tue, Jan 19, 2016 at 03:15:01PM +0100, Sumit Bose wrote:
On Mon, Jan 18, 2016 at 04:48:40PM +0100, Jakub Hrozek wrote:
> On Mon, Jan 18, 2016 at 01:53:27PM +0100, Sumit Bose wrote:
> > Thank you for the review. New version attached.
> >
> > bye,
> > Sumit
>
> Thank you, the patch now look good to me and seem to work well. I see
> this message in adcli output:
> ! Couldn't set userAccountControl on computer account:
CN=ADCLIENT,CN=Computers,DC=win,DC=trust,DC=test: Insufficient access
yes, this is expected. adcli can update other attributes as well, but in
general the permissions the host princiapal has are not sufficient.
>
> but the keytab was updated successfully.
>
> I also wonder if you considered using the -S option to run the update
> against the server sssd talks to? From experience I know that many
> environments restrict access to parts of their AD domain. It's not a big
> deal, though, because failing to renew the keytab is non-fatal..
That's a good idea. I added three new patches on top of the existing
ones to add this. I used the failover code to get the active server
because I found this more accessible here compared to getting the LDAP
connection internals to call getpeername(). If you don't like it I think
I would prefer to just commit the initial 3 patches and create a ticket
to add -S support.
bye,
Sumit
Thank you, the patches seem to work well. I tested by assigning a client
to a site, then the LDAP lookups as well as the keytab renewal
communicated with the DC in site. Then I hardcoded a DC with 'ad_server'
and the communication was always directed to the hardcoded DC.
ACK
I will just run Coverity and CI before pushing to be sure..