<div dir="ltr">Hi Sumit,<div><br></div><div>Thanks for the suggestion. I'll have to give this some thought, since we have 100+ AD servers, this might not be well received by the AD team. If anyone can think of a better mousetrap than this, let me know.</div>

<div><br></div><div>Thanks,</div><div>Brian</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 14, 2013 at 9:37 AM, Sumit Bose <span dir="ltr"><<a href="mailto:sbose@redhat.com" target="_blank">sbose@redhat.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Wed, Aug 14, 2013 at 09:19:17AM -0400, Brian Lee wrote:<br>
> Hi All,<br>
><br>
> Our current account management policy requires that users change their AD<br>
> passwords via a special portal, however I've noticed that this can be<br>
> bypassed by issuing passwd on a Linux system while logged in with AD<br>
> credentials, thus changing their AD password.<br>
><br>
> Any thoughts on the best way to prevent this action?<br>
><br>
> What I've considered so far is removing the trust in AD, effectively<br>
> creating a one-way trust, but that would limit functionality for future<br>
> interoperability.<br>
><br>
> Additionally, we could change the permissions for passwd on each Linux<br>
> system, but this would be somewhat hackish and also complicated to enforce,<br>
> since we're waiting on Foreman + Puppet to properly be integrated into<br>
> Katello for our configuration management solution.<br>
><br>
> Any way to restrict this via the FreeIPA UI?<br>
<br>
</div></div>I think the only safe way to achieve this is to block port 464 on the AD<br>
servers for the Linux hosts. Because basically what passwd is doing here<br>
via SSSD is to change the Kerberos password. The same can be done with<br>
the kpasswd command, it does not require any privileges the user only<br>
needs to know his current password. So even if we add an option to force<br>
SSSD to reject password changes for users from trusted domains there are<br>
other ways for users to change the password which cannot be controlled<br>
by IPA.<br>
<br>
Please note that changing the AD password with kpasswd would even work<br>
without trust.<br>
<br>
HTH<br>
<br>
bye,<br>
Sumit<br>
<br>
><br>
> Thanks,<br>
> Brian<br>
<br>
> _______________________________________________<br>
> Freeipa-users mailing list<br>
> <a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
> <a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
<br>
_______________________________________________<br>
Freeipa-users mailing list<br>
<a href="mailto:Freeipa-users@redhat.com">Freeipa-users@redhat.com</a><br>
<a href="https://www.redhat.com/mailman/listinfo/freeipa-users" target="_blank">https://www.redhat.com/mailman/listinfo/freeipa-users</a><br>
</blockquote></div><br></div>