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.. _______________________________________________ sssd-devel mailing list sssd-devel@lists.fedorahosted.org https://lists.fedorahosted.org/admin/lists/sssd-devel@lists.fedorahosted.org
