Active Directory and password filter

[Greg Beresnev]

hi all,

I'm writing a password filter DLL, to be installed on the
Active Directory primary domain controller. Whenever user
password change occurs, or computer account is reset, my
routines are invoked by the LSA. My question is, using
UserName and Relative Identifier (RID) provided to me, is
there any way I can distinguish between a username that
just happens to end with a dollar sign ($) and a machine
name (all of which seem to be ending with dollar sign too)?
The only thing that seems to make sense is to either
document this restriction (i.e. my password filter DLL
won't work with user names ending with $), or somehow use
the relative ID + some Windows API routines to get more
information about the password change target?

thanks in advance,

regards,
Greg

[Joe Richards [MVP]]

You would have to look the object up. I don't recall the functions being called
for computer password changes though. There isn't any way to control the
password rules for computers so that they could set a proper password if you
failed it.

To look the user up, you have to get the domain SID, tack on the RID and then
you have the full object SID which you should be able to resolve.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

[Greg Beresnev]

hi Joe,

thanks for the quick response. after having a closre look
at the password filter implementation, there doesn't
actually seem to be a way for me to achieve my task, since
one of my routines (invoked by the LSA) only receives user
name, full name and a password... i.e. no RID or any other
sort of unique identifier... so at that point, I have no
way of telling if this is a computer account change or a
user name whose name ends with a $. Back on Windows NT
primary domain controllers this wouldn't have been an
issue (since I don't recall being able to do things such
as creating 'Computer' objects etc)... oh well, maybe at
some stage in the future enough people will consider this
to be an issue (I'm guessing from the lack of results
returned by google that a very small # of password filter
implementations are being used world-wide) and Microsoft
either modifies their current password filter
implementation guidelines and available API routines
(current ones being PasswordFilter, InitializeChangeNotify
and PasswordChangeNotify), or creates a new set of them.

thanks again,

regards,
Greg

>.
>

[Joe Richards [MVP]]

You certainly had computer objects in Windows NT. They were just like they are
in Active Directory, basically user objects with a $ tacked on the end to make
them "hidden". This also goes for domain trust accounts as well.

It has been a long while since I have played with filters, but I think it was
password filter was the one that didn't pass the RID. It doesn't matter though
because you get the account name which is a unique on the domain, it has to be.
You have a flat namespace for samaccountnames. You don't need the RID.

The Change Notify routine I believe gives a RID and username.

Again, are you positive that you are seeing password change operations of
computer accounts?

[Greg Beresnev]

hi Joe,

There's basically 3 routines that need to be implemented
by a password filter (InitializeChangeNotify,
PasswordFilter and PasswordChangeNotify). First one is
invoked when DLL is loaded on machine start-up and is not
an issue. The other two are invoked by the LSA when some
sort of password change occurs. It looks to me as though
for user password changes, PasswordFilter is invoked
first, and if that succeeds and the password ends up being
changed in SAM database, PasswordChangeNotify gets
invoked. Now, it would appear as though if a
new 'Computer' object is created in Active Directory, or
the computer password is reset (for example, using
netdom.exe utility), PasswordChageNotify (the one that
receives RID) is invoked. Like you mentioned earlier, I
guess my best bet would be to use some Windows API
routines to obtain domain SDI, combine it with RID and
then once again use some API routine to establish whether
its a user or not. Guess its time for some digging around
through MSDN and google... You are correct in saying that
the name that I get is unique (sAMAccountName), but I
still need to establish if its a Computer or a user :)

thanks again
regards,
Greg

>.
>

[Joe Richards [MVP]]

> There's basically 3 routines that need to be implemented
> by a password filter (InitializeChangeNotify,
> PasswordFilter and PasswordChangeNotify). First one is
> invoked when DLL is loaded on machine start-up and is not
> an issue. The other two are invoked by the LSA when some
> sort of password change occurs. It looks to me as though
> for user password changes, PasswordFilter is invoked
> first, and if that succeeds and the password ends up being
> changed in SAM database, PasswordChangeNotify gets
> invoked.

All of this is absolutely correct.

> Now, it would appear as though if a
> new 'Computer' object is created in Active Directory, or
> the computer password is reset (for example, using
> netdom.exe utility), PasswordChageNotify (the one that
> receives RID) is invoked.

Are you actually seeing this or are you thinking it would happen? If you see it,
I will pull out my password monitoring DLL and load it on a VM and see if I see
the same. The last time I looked though, I don't recall this occurring.

[Greg Beresnev]

hi Joe,

I'm definitely seeing this (I have logging enabled in my
password filter DLL). For your information, I'm using a
password filter installed on Windows 2003 Server primary
domain controller with Active Directory configured.

thanks in advance for your assistance,

regards,
Greg

>.
>

[Greg Beresnev]

any luck with that password monitoring DLL, Joe? :)

regards,
Greg

[Joe Richards [MVP]]

Sorry I got tied up with messaging issues at work, I will try to look at it this
weekend.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

[Joe Richards [MVP]]

Yeah I got the change notification filter installed and sure enough a computer
object showed up. I need to rev up some old test environments to see if I truly
didn't see it before but I am pretty sure I didn't because I wondered back in
2001 what the passwords were like that the computers were using...

This brings up all sorts of questions though, what happens if a filter bounces a
password for a computer for instance?

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

[Greg Beresnev]

My guess would be that the same thing that occurs when the
password filter rejects a proposed change to a user
password i.e. the entire password changing gets aborted
(in case of computer objects, the password for a machine
wouldn't be reset? or, in case of a new computer object
being created, we'd receive 'failure to create a new
computer object such and such' messagebox?)

regards,
Greg

>.
>

[Joe Richards [MVP]]

Ok I wrote a newer filter that didn't have all the extra bells and whistles my
old one had and dumped to debug.

PasswordFilter is NOT called by computer password changes, PasswordChangeNotify
is called though. That should be enough for you to do what you need.

joe

--
Joe Richards Microsoft MVP Windows Server Directory Services
www.joeware.net

[Greg Beresnev]

thanks Joe, I guess off I go to search MSDN for the
wonderful LSA-related API routines which deal with domain
SIDS and RIDS :)

thanks again
regards,

Greg

>.
>

[Joe Richards [MVP]]

Not sure I understand why you need to. Based on the results from PasswordFilter
and PasswordChangeNotify export functions you should know what you need.

If a useraccount hits PasswordFilter but doesn't hit PasswordChangeNotify, it
was rejected by one or more PasswordFilter exports.

If a useraccount hits PasswordChangeNotify but never hit PasswordFilter, it is a
computer account.

If it hits both it was a user account and the password was changed.

You could just dump out anything that hits PasswordChangeNotify that didn't hit
PasswordFilter just a few seconds (probably milliseconds actually) prior.

[Greg Beresnev]

hi Joe,

The approach you've described will work as expected
(although I thought if I could determine with just a
couple of lines of code if a given RDN corresponds to a
computer entity, that'd still be the preferred solution...
not sure what the downsides of that approach are). I mean,
I'd have some global container for storing the names of
all the users whose name ends with $ (to keep the memory
usage to a minimum + efficiency to a maximum! :)), who
have successfully passed PasswordFilter check but are yet
to have corresponding PasswordChangeNotify routine
invoked.

Hope you agree that ideally there should be no need to
have any sort of assumptions/limitations based on the time
between invocations of PasswordFilter/PasswordChangeNotify
(i.e. the kind of thing mentioned in the last sentence of
your previous post)

Since password filter DLL is supposed to support multi-
threading I'll just have to be careful to ensure multiple
threads aren't interfering with each other's access to
this global 'username' container.

>.
>