On the AD side, they limit the potential to change the AD password by
deploying a modified the msgina.dll. Otherwise, the user still has the ways
to throw a wrench in the system, we're just doing our best to limit the
opportunity for this action.
On Wed, Aug 14, 2013 at 10:32 AM, Simo Sorce wrot
On Wed, 2013-08-14 at 09:48 -0400, Brian Lee wrote:
> Hi Sumit,
>
>
> 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.
Do you also
On 14.8.2013 15:48, Brian Lee wrote:
Hi Sumit,
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.
Thanks,
Brian
On Wed, Aug 14, 2013
Hi Sumit,
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.
Thanks,
Brian
On Wed, Aug 14, 2013 at 9:37 AM, Sumit Bose wrote:
> On We
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
> creden
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 t