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