Anonymous_User Absent Member.
Absent Member.
415 views

Password Sync AD driver


Recently we had an issue where we received a lot of "old" passwords from
an AD, which caused a major amount of issues for a significant number of
users. I refer to them as old because the passwords were not recent
password changes. So these were cached passwords potentially from a
domain controller that could not contact the remote loader or some sort
of restore, possibly of the registry? Whatever the case it has lead to
a more in depth understanding of how passwords are synchronized which
has of course led to questions\comments.

1- Why are passwords cached on the individual DC's when the engine is
not connected to the remote loader? When a password change cannot be
processed due to an unassociated object the password is cached by the
Remote Loader, and each additional password change overwrites the
previous, so when the password is finally processed only the latest
password is synchronized. If the engine is not connected to the remote
loader and a user, who is associated, changes their password multiple
times on multiple dc's the passwords will be processed in the order the
Remote Loader receives them, meaning the latest password change might
not be the last one synchronized. If the Remote Loader cached the
passwords and successive changes were made they would be overwritten and
the latest password would be synchronized.

2- As far as I know, the AD driver parameter pub-password-expire-time
will specify the number of minutes a driver will attempt to sync a
password, the time is from when the remote loader receives the password.
Wouldn't it make more sense for the value to expire a password based on
the time it was set?


Just looking for feedback\thoughts.

Thanks.


--
Kgallogly
------------------------------------------------------------------------
Kgallogly's Profile: https://forums.netiq.com/member.php?userid=2387
View this thread: https://forums.netiq.com/showthread.php?t=44986

Labels (1)
0 Likes
10 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 1- Why are passwords cached on the individual DC's when the engine
> is not connected to the remote loader? When a password change cannot
> be processed due to an unassociated object the password is cached by
> the Remote Loader, and each additional password change overwrites
> the previous, so when the password is finally processed only the
> latest password is synchronized. If the engine is not connected to
> the remote loader and a user, who is associated, changes their
> password multiple times on multiple dc's the passwords will be
> processed in the order the Remote Loader receives them, meaning the
> latest password change might not be the last one synchronized. If
> the Remote Loader cached the passwords and successive changes were
> made they would be overwritten and the latest password would be
> synchronized.


Yes... having DCs down is bad. Don't do it! Well it's windows, so you
probably have them down every other day or so for patches. Okay, so it
wasn't in your control, or as you mentioned somebody restored part of
the registry and instead of doing it surgically restored the whole thing
including the PWFilter key (and subtree) which caused problems. This is
all "bad stuff", but see more below.

> 2- As far as I know, the AD driver parameter
> pub-password-expire-time will specify the number of minutes a driver
> will attempt to sync a password, the time is from when the remote
> loader receives the password. Wouldn't it make more sense for the
> value to expire a password based on the time it was set?


Exactly. No fast forward to 2012 (or 2011) and Novell released a neat
new option which controls the password expiration while still on the DCs
for this very reason.

Code:
- ----------
<definition display-name="DC Passwords TimeToLive (minutes)"
name="pub-filter-password-time-to-live" type="integer">
<description>Specify the number of minutes the passwords will be
stored in the DC registry</description>
<value>0</value>
</definition>
- ----------

Be sure you have a pretty recent shim, and the latest password sync
filters on DCs, and then add this to your driver configuration settings.
Set to value of your choice and go from there. Warning, you may not
like life if your DCs continue to have reliability issues causing comms
problems to the RL box.

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQgCXlAAoJEF+XTK08PnB5c6YP/1quRYZ8BsD20SeQJCCtAWz1
AGTh22ncs2NZ/fHewbOx+u+j8hgEXiw0jewfUcWfLcuj0gMWITM9JlXf9AHwM6vK
TnAeWzZozJMGerlsOvhjBq7AjqzDRxuahBPcSmLgQtXJYInAV3HuH1UoLBxl130l
uGS9vy3CZJ0CCfGJtDDku6Nq9imgut1RumATtHBDElcHEuey5cu39dkJAdBMRTYI
WwvAE7mLvMKTJdjjt+IJXrlGHu9QjSwtH94thQIwroh9HQd18DoK9hrjtSJOONNF
OogidylfjkyW3QLVuFVscyp2Ow5tShVYYB+3jjS2JjxeBiPi6TezfAbfheTeYZ+5
jl1T8KHzYwUmjPrV90LSAoz2AyV7w7SCOpi5vvs/bm/1nRrnzapF37YCKoIs2d5A
J3TWSgsfFKNKW8QRVbp52/u7Nzr2U1HnSh2U0NF+DW7c7e6idjNX77hMjtQLoR9w
GdRogp5R2D4tIxs5x7+feKg16IbyiEm9uxmsa96kyGRHM+QS9nsl1cRD0mRqB+2R
93BgaEHtfsvOMoqMBR4v0Fydr4xApBr0YRTehIFpiqFnb6pDQItHHy8S6pTQOZGb
Tl/ogjmXWhrcnnN/HYRw9BBfzzNZU3hCFNnc5+3/8QMGEwkuptUUrf+YKTEDOi1c
7EThNR99nj/J1der9+dm
=VCAu
-----END PGP SIGNATURE-----
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver


Thanks for the reply...Yes, all "bad stuff" and we have very limited
access to AD and no administrative rights or control. But in the first
question I was asking more about the way passwords are cached when the
engine is not connected, for example a firewall/network issue or upgrade
of the engine side (If you do not have another server in driver set).
Passwords are cached at each DC, and if multiple changes are made on
multiple DC's it is not guaranteed that the latest password will be
synchronized last when a connection is re-established.


I have been testing pub-filter-password-time-to-live, it is a nice added
feature. However, it appears to check the TimeToLive value only after
it cannot send the change to the remote loader. So if a registry is
restored, it would process any password changes that were restored. So
if the pub-password-expire-time was to expire from time the password
was set it would ensure no passwords older than the specified time would
ever sync.


--
Kgallogly
------------------------------------------------------------------------
Kgallogly's Profile: https://forums.netiq.com/member.php?userid=2387
View this thread: https://forums.netiq.com/showthread.php?t=44986

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> I have been testing pub-filter-password-time-to-live, it is a nice
> added feature. However, it appears to check the TimeToLive value
> only after it cannot send the change to the remote loader. So if a
> registry is restored, it would process any password changes that were
> restored. So if the pub-password-expire-time was to expire from
> time the password was set it would ensure no passwords older than the
> specified time would ever sync.


Agreed... I have not tested the details thoroughly, but you are probably
right. With that said, why would you ever restore this part of the
registry?? The only answer I can come up with is, "Because we didn't
know that we were... our restore process isn't made for a specific
purpose but just restores everything ever." Well, I'm not sure there's
a great fix for that, though I guess that side could be enhanced again
to check the timestamps more often or at a better time. The description
and intent of this configuration option would seem to apply always, not
just when a connection failure happens. The DCs do not just try to
resend events over and over after their first failure, so only checking
AFTER a failure seems like it is wrong, assuming that is really how it
works.

I'd be interested in hearing how this happened in the first place. If
it is a registry restore it's pretty bad luck having somebody restore it
incorrectly (with entire keys that were not meant to be restored) with a
backup from a time when there were a bunch of old passwords stuck. Now
I guess I need a windows VM to test all of this....

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQgD+SAAoJEF+XTK08PnB5myQP/3KFG2UGspVVB4doNzVl3yiO
9fjN8nDrdpH/o2Ue3A/zewifhE2fLQENIp8uuemOhOrWKKhtvKItFyisim9zV0C7
oCQeAn9wF2XMhgvNAlpSGf8c/WpZlrE0fbcKNMjLh9bisZItEPKP/4MVVFgXKuVZ
LPpNURbnn4DfwU6TRs5ZaA16aZjpEtF9Bc+GQc4DHRcdpqmf4QRIphFCNpj7Z7ub
sMxZM0sWQ7pavZ1VD6vLMCQHEKQ9bDPvcrjE4wrrjd3/3z90sPsSMbiB8ADfo4L6
qEo9pmY+XyeNOx0Pdj4F9PT7aa4XDljXy1EocO4k+vnkReGBuD3/UzsMVhrjA2PD
q/f+299qX3ijSsScfJJ42whpwxY+ixKhLcCANuM4zDyStl24nK3IHyRdEYRMV9r1
mJOD0dUliXUKTfay8Hn2XO0UKnl+f2hU7HvKw2Clw7wCEJGHV3JCGyZ+UktArPlK
iw5AVjwKh5PNtTkiA/Au+gaM2sy3oTMiD5GwfPihOxPhG2vLxY3y13ZvLjZGj3O5
1QQHx1eXaxc6oIyz629Nv5o2v/JoSAJuE3tvQ7pZj6AR8GlqQyZD9vCAin3uOAam
1ul/ST0fvE0wOpKIw6HWAv5MZCmq//aLGjIPx0JEuIriPo17+6Xlr3fpdT11I0ez
c9NH4WoQsutGansbgGAz
=Jtzo
-----END PGP SIGNATURE-----
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver


Not sure root cause will ever be fully known. I have spent a lot of
time in the lab using process monitor to monitor registry keys and
psexec to run regedit as system working though possible scenarios. This
has led me to the two questions which are think would be reasonable
enhancements, just wanted to get others opinions from a different point
of view.

Thanks,


--
Kgallogly
------------------------------------------------------------------------
Kgallogly's Profile: https://forums.netiq.com/member.php?userid=2387
View this thread: https://forums.netiq.com/showthread.php?t=44986

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver

On Thu, 18 Oct 2012 18:04:01 +0000, Kgallogly wrote:

> Not sure root cause will ever be fully known. I have spent a lot of
> time in the lab using process monitor to monitor registry keys and
> psexec to run regedit as system working though possible scenarios.


For additional fun, you might try Sysinternal's "debug view" tool. The
password filters are debug view enabled.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver

On Thu, 18 Oct 2012 15:04:02 +0000, Kgallogly wrote:

> Recently we had an issue where we received a lot of "old" passwords from
> an AD, which caused a major amount of issues for a significant number of
> users. I refer to them as old because the passwords were not recent
> password changes. So these were cached passwords potentially from a
> domain controller that could not contact the remote loader or some sort
> of restore, possibly of the registry?


Ouch.

You might want to find out exactly what happened. Did you have a DC that
couldn't communicate for a long period of time (that's bad)? Did somebody
restore a DC to a point in the past (that's also bad, but differently
so)? Or did somebody manage to restore the Registry (where password
changes are cached), which would also have meant mucking with the rights
in the Registry to be able to have backed up the password keys in the
first place, and to restore them later (again, bad)?


> 1- Why are passwords cached on the individual DC's when the engine is
> not connected to the remote loader?


IIRC, the DC only caches passwords when *it* can't talk to the DC where
the RemoteLoader is running. Otherwise, if it can, then the passwords
cache on the DC with the RL if the RL/engine communication is broken.
It's been a while since I watched this, though, so I could be wrong.


> 2- As far as I know, the AD driver parameter pub-password-expire-time
> will specify the number of minutes a driver will attempt to sync a
> password, the time is from when the remote loader receives the password.


Yes, I believe you're correct.


> Wouldn't it make more sense for the value to expire a password based on
> the time it was set?


I'm not sure that's currently possible, but taken at face value, it seems
like a sensible enhancement.


--
--------------------------------------------------------------------------
David Gersic dgersic_@_niu.edu
Knowledge Partner http://forums.netiq.com

Please post questions in the forums. No support provided via email.

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver


Ouch is an understatement! 🙂 We have very limited access to AD.

As far as password caching, using process monitor from sysinternals in
our LAB, I was able to confirm that password changes are cached on each
individual DC if the engine is not connected. If the remote loader was
is running I would think passwords should be cached by the RL to ensure
password change order.


As far as time out being from when password was set, I agree, not sure
if possible, but worth asking.

Thanks,


--
Kgallogly
------------------------------------------------------------------------
Kgallogly's Profile: https://forums.netiq.com/member.php?userid=2387
View this thread: https://forums.netiq.com/showthread.php?t=44986

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver

On 18.10.2012 19:54, Kgallogly wrote:
>
> Ouch is an understatement! 🙂 We have very limited access to AD.
>
> As far as password caching, using process monitor from sysinternals in
> our LAB, I was able to confirm that password changes are cached on each
> individual DC if the engine is not connected. If the remote loader was
> is running I would think passwords should be cached by the RL to ensure
> password change order.
>
>
> As far as time out being from when password was set, I agree, not sure
> if possible, but worth asking.
>
> Thanks,


What about the situation where you switch from running the RL on one DC
to the RL on another DC?

If, as suggested the DCs continue to send passwords to the RL (when it
is running, but not connected to the engine). You risk losing password
changes from the point when the engine disconnected from old RL DC and
connected to the new RL DC.

I think the current design makes the most sense in regards to this
specific aspect
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver


In this scenario stopping the remote loader service would cause the
passwords to cache on the individual DC's. Once hostname is updated for
password filter the changes would be sent to new RL.


--
Kgallogly
------------------------------------------------------------------------
Kgallogly's Profile: https://forums.netiq.com/member.php?userid=2387
View this thread: https://forums.netiq.com/showthread.php?t=44986

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Password Sync AD driver

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I'm not positive, and I am not sure how to verify, but I think the
reason that passwords do not magically flow from DCs to the RL is
because of how the connection works. Going from memory, the filter code
captures the password upon password change and immediately writes it to
another thread in memory; the reason for this is that the filter
operation blocks lsass which handles things like password changes,
logins, etc. Anyway the password is moved to another spot in memory
where it is then encrypted with (I think) a local DC key and it is then
stored in the registry. Either this same second thread, or a third one
notified by this second one, will inform the RL of a pending password.
This is why password sync operations are instantaneous even when other
things require waiting for synchronization and the polling interval.

Once notified the RL goes and pulls the password from the DC. Because
of this I believe the connection from he engine is required. Why?
Because the authentication used to talk to the remote DCs comes from the
driver config which is provided when the engine connects to the RL. No
engine, no credentials, no ability to pull passwords from the DCs.

- From here I'm pretty sure that the password is encrypted with the
receiving machines (RL's) public key and then the RL machine goes from
there and does everything else. Again, I don't know how to verify this,
but it's what I remember from an explanation from the developer many
years ago. The intent was to minimize any interference with the OS's
operations and also to provide the best security possible (no cleartext
passwords other than in memory, and encryption using MAD encryption so
if you have the keys you basically own the domain anyway).

Good luck.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQgG3wAAoJEF+XTK08PnB5GNUP/1RGmQJOroi9Xun7CxOtMACt
TdD7cJ1M9t1QOWcBJ3uIDKythkz1SKMAfpUEWFWCAQgkWK3eXrmS2hcWc+50Lj6g
j0Hyns5F+1l3Gf7juGmP7VNcefvVP6p0wQLP+p8dtZSsNeWjSf3vWsm05qfBxjnz
+NPPXgqVWwgL4T8ymBkCdxIaeqR95SLBMA3I4ANAIUW1FauJj9F9FTAZB27uFkal
nmslurjbkv0MdN+5V0DzR++/jIG/LALX2uD4wlhsjegPMUqKtqSVtNbORLhf49kc
komr3qTk2ENgoJLEI8OpBF1ihPNpkgGy0mvKxJKwbdwZC7DjwBZ+oaw3aM4Lcd+c
24SRPVxo8Xvim21wwmitefnd4jedAWfIVPNrEUOU7JlXHbuiamQHfCYyoVUkyvjn
fclnwv5PyUvpSZTlhCRHJN+7zjJRC3vn9aeyGEnAL0iHpd40bqa6Gr78CMW5nQZX
I5xrBMjk7RD1r256Q86bCwxV+f9SooYQXu1+aui0VLZvcjw/qT01g1KsOmnEbXd5
7crE9yXqN+3lJZMWjq8ba9zMauMZAH6POqi9E/3q3wmwFuFtpDhUa6e58HfroJGr
zRle6r1iwDQV9iokVOQ921CsvVmXPWnUBqiQcAe+EiT/4Zc/pA1BRkVNXNkO41sf
9bP3BGmsypahODXfV5fm
=T2v7
-----END PGP SIGNATURE-----
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.