password replication

[Alberto Viana]

I have a replication setup (389 and AD):


389-Directory/1.3.2.19 B2014.201.1231


We are implementing password police on both side (and password expiration).
When the account has expired on AD side (It means that on AD side I have
the flag "user must change password" set on an user) , when I try to change
password on 389 side, I see the following error:

[03/Jul/2017:10:47:07 -0300] NSMMReplicationPlugin - windows sync -
agmt="cn=AD - GTI-DF-DC01" (gti-df-dc01:636): AD entry CN=Teste
Marcelo,OU,test,DC=my,DC=domain set "user must change password at next
logon".

And the password is not changed on AD side.


I thought that could be something about permission on my replication login,
so I made a script in perl to change password directly on my AD, and with
this script (using the same login that I uses on my replication) the
password is changed.

Can you detail me a little bit better how replication occurs? Or point me
why when this flag is set the replication plugin is not be able to change
the password on AD side?


My first guess is:
The replication plugin try to bind this user first (to check if the user
already has this password) and when receives this error (user must change
password), so it does not try to change the password.

[William Brown]

On Mon, 2017-07-03 at 11:21 -0300, Alberto Viana wrote:
>  I have a replication setup (389 and AD):
>  
>  
>  389-Directory/1.3.2.19 B2014.201.1231
>  
>  
>  We are implementing password police on both side (and password expiration).
>  When the account has expired on AD side (It means that on AD side I have
>  the flag "user must change password" set on an user) , when I try to change
>  password on 389 side, I see the following error:
>  
>  [03/Jul/2017:10:47:07 -0300] NSMMReplicationPlugin - windows sync -
>  agmt="cn=AD - GTI-DF-DC01" (gti-df-dc01:636): AD entry CN=Teste
>  Marcelo,OU,test,DC=my,DC=domain set "user must change password at next
>  logon".
>  
>  And the password is not changed on AD side.
>  
>  
>  I thought that could be something about permission on my replication login,
>  so I made a script in perl to change password directly on my AD, and with
>  this script (using the same login that I uses on my replication) the
>  password is changed.
>  
>  Can you detail me a little bit better how replication occurs? Or point me
>  why when this flag is set the replication plugin is not be able to change
>  the password on AD side?
>  
>  
>  My first guess is:
>  The replication plugin try to bind this user first (to check if the user
>  already has this password) and when receives this error (user must change
>  password), so it does not try to change the password. 
I don't think we try and bind as the user to change their password -
because we can't always know the passwords are in sync. I would have
though that the account that binds to AD to do the replication would
lack the permission to do the password reset. Is there a flag on the AD
account perhaps marking it for a force reset? 


-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Alberto Viana]

William,

Yes, there's a flag on AD that forces users to reset their passwords, and
we're using it.... that is the same flag that is set when an account has
been expired (forcing the user to reset his password).

I don't think that is the problem, my replication user has FULL permission
in the whole tree, and like I said before I made a script in perl to change
password directly in AD using the exactly same user that I use on
replication, and it works, so I've been able to change the user password
through this script even if this flag is set on AD side.

Here's a snippet of it:

$mesgad = $ldapad->bind("CN=389 Sync Account,OU=APPS,DC=my,DC=domain",
                        password => "MY_USER_PASS",
                        version => 3 );


        if ($mail =~ /my_user_test/) {
                printf "$dnad -- $mail -- $san\n";

                $mesgad = $ldapad->modify( $dnad,
                                        replace => {
                                                unicodePwd => $newUniPW,
                                                }



So, basically it does a ldap operation to replace the user password (I
think that is the same behavior of 389 plugin, am I right?)


On Tue, Jul 4, 2017 at 9:10 PM, William Brown <wibrown(a)redhat.com&gt; wrote:

>  On Mon, 2017-07-03 at 11:21 -0300, Alberto Viana wrote:
>  > I have a replication setup (389 and AD):
>  >
>  >
>  > 389-Directory/1.3.2.19 B2014.201.1231
>  >
>  >
>  > We are implementing password police on both side (and password
>  expiration).
>  > When the account has expired on AD side (It means that on AD side I have
>  > the flag "user must change password" set on an user) , when I try to
>  change
>  > password on 389 side, I see the following error:
>  >
>  > [03/Jul/2017:10:47:07 -0300] NSMMReplicationPlugin - windows sync -
>  > agmt="cn=AD - GTI-DF-DC01" (gti-df-dc01:636): AD entry CN=Teste
>  > Marcelo,OU,test,DC=my,DC=domain set "user must change password at next
>  > logon".
>  >
>  > And the password is not changed on AD side.
>  >
>  >
>  > I thought that could be something about permission on my replication
>  login,
>  > so I made a script in perl to change password directly on my AD, and with
>  > this script (using the same login that I uses on my replication) the
>  > password is changed.
>  >
>  > Can you detail me a little bit better how replication occurs? Or point me
>  > why when this flag is set the replication plugin is not be able to change
>  > the password on AD side?
>  >
>  >
>  > My first guess is:
>  > The replication plugin try to bind this user first (to check if the user
>  > already has this password) and when receives this error (user must change
>  > password), so it does not try to change the password.
>
>  I don't think we try and bind as the user to change their password -
>  because we can't always know the passwords are in sync. I would have
>  though that the account that binds to AD to do the replication would
>  lack the permission to do the password reset. Is there a flag on the AD
>  account perhaps marking it for a force reset?
>
>
>  --
>  Sincerely,
>
>  William Brown
>  Software Engineer
>  Red Hat, Australia/Brisbane
>
>
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>

[William Brown]

On Mon, 2017-07-10 at 16:39 -0300, Alberto Viana wrote:
>  William,
>  
>  Yes, there's a flag on AD that forces users to reset their passwords, and
>  we're using it.... that is the same flag that is set when an account has
>  been expired (forcing the user to reset his password).
>  
>  I don't think that is the problem, my replication user has FULL permission
>  in the whole tree, and like I said before I made a script in perl to change
>  password directly in AD using the exactly same user that I use on
>  replication, and it works, so I've been able to change the user password
>  through this script even if this flag is set on AD side.
>  
>  Here's a snippet of it:
>  
>  $mesgad = $ldapad->bind("CN=389 Sync Account,OU=APPS,DC=my,DC=domain",
>                          password => "MY_USER_PASS",
>                          version => 3 );
>  
>  
>          if ($mail =~ /my_user_test/) {
>                  printf "$dnad -- $mail -- $san\n";
>  
>                  $mesgad = $ldapad->modify( $dnad,
>                                          replace => {
>                                                  unicodePwd => $newUniPW,
>                                                  }
>  
>  
>  
>  So, basically it does a ldap operation to replace the user password (I
>  think that is the same behavior of 389 plugin, am I right?) 
I would assume so - but I have not worked on the AD sync code myself. I
was hoping only to eliminate a trivial case. :( 




-- 
Sincerely,

William Brown
Software Engineer
Red Hat, Australia/Brisbane

[Alberto Viana]

Anyone else that could point me why is this happening?



On Tue, Jul 11, 2017 at 9:08 PM, William Brown <wibrown(a)redhat.com&gt; wrote:

>  On Mon, 2017-07-10 at 16:39 -0300, Alberto Viana wrote:
>  > William,
>  >
>  > Yes, there's a flag on AD that forces users to reset their passwords, and
>  > we're using it.... that is the same flag that is set when an account has
>  > been expired (forcing the user to reset his password).
>  >
>  > I don't think that is the problem, my replication user has FULL
>  permission
>  > in the whole tree, and like I said before I made a script in perl to
>  change
>  > password directly in AD using the exactly same user that I use on
>  > replication, and it works, so I've been able to change the user password
>  > through this script even if this flag is set on AD side.
>  >
>  > Here's a snippet of it:
>  >
>  > $mesgad = $ldapad->bind("CN=389 Sync Account,OU=APPS,DC=my,DC=domain",
>  >                         password => "MY_USER_PASS",
>  >                         version => 3 );
>  >
>  >
>  >         if ($mail =~ /my_user_test/) {
>  >                 printf "$dnad -- $mail -- $san\n";
>  >
>  >                 $mesgad = $ldapad->modify( $dnad,
>  >                                         replace => {
>  >                                                 unicodePwd => $newUniPW,
>  >                                                 }
>  >
>  >
>  >
>  > So, basically it does a ldap operation to replace the user password (I
>  > think that is the same behavior of 389 plugin, am I right?)
>
>  I would assume so - but I have not worked on the AD sync code myself. I
>  was hoping only to eliminate a trivial case. :(
>
>
>
>
>  --
>  Sincerely,
>
>  William Brown
>  Software Engineer
>  Red Hat, Australia/Brisbane
>
>
>  _______________________________________________
>  389-users mailing list -- 389-users(a)lists.fedoraproject.org
>  To unsubscribe send an email to 389-users-leave(a)lists.fedoraproject.org
>
>