Re: ADAM not honoring account lockout policy on Workgroup 2K3
- From: "Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Mon, 11 Dec 2006 09:58:18 -0600
The nice thing about going to SSL is that you can possibly use the ASP.NET
AD membership provider instead of rolling your own, and can possibly also
use fast concurrent binding, which might give you a little speed increase.
Also, with the cert for ADAM, you can probably get away with using a
self-signed cert if you can control the clients that will access ADAM. You
can use makecert or selfssl for that.
It is generally better to not use self-signed certs and they become very
impractical if you have lots of different clients, but with a small surface
area, I don't see it being a big deal.
Glad our other stuff has been helpful. It looks like you are well on your
way.
Someone should probably file a bug on the digest auth thing. That can't be
the desired behavior. :) Dmitri?
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Jim Pierson" <jpierson@xxxxxxxxxxxxxxxxxxx> wrote in message
news:gf6dnXG2-5Lw4ODYnZ2dnUVZ_t6qnZ2d@xxxxxxxxxx
Joe..... you hit it on the head!
Basic auth it works..... with Digest it don't.
Guess I'm creating a cert for my server.... blah..........
BTW... I want to take a moment to thank you and Lee. If it wasn't for the
various postings from you two, I would have never gotten as far as I have.
It got to a point where I was searching on your names rather than the
subject
I was looking for and getting better results.
Thanks again.... both of you.
Jim
"Joe Kaplan" <joseph.e.kaplan@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:ekMF1gTHHHA.3616@xxxxxxxxxxxxxxxxxxxxxxx
Is this happening in conjunction with digest auth (you mentioned you were
using that in your own provider)? If so, do you get the expected
behavior with a simple bind? Perhaps there is a bug in ADAM where
account lockout isn't enforced for Digest or something? I'd have to test
it...
SSL for ADAM isn't really a bad thing. What was the big resistance to
using it?
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Jim Pierson" <jpierson@xxxxxxxxxxxxxxxxxxx> wrote in message
news:_4udnW_kKOWcxODYnZ2dnUVZ_sudnZ2d@xxxxxxxxxx
These are pure ADAM principals. I'm prototyping the security for an
extranet
application that by company policies can't even look sideways at AD. So
we
created a 2K3 server outside of the domain and installed ADAM and IIS.
I'm having to role-my-own membership provider since the existing .Net
provider doesn't support Digest and we don't want to go SSL or plain
text.
I definately haven't changed the ADAMDisablePasswordPolicies, it's still
at 0.
That's one of the first things I looked at.
I just enabled failure audits (success was already on) as you
suggested, and
nothing shows. I see my RDP logon as well as the remote debugger
session
but nothing else. I can see the badPasswordCount go up to 8 (the policy
limit is set to 5) and lockoutTime is still 0.
Would the authentication of ADAM principals even show in the event log?
I'm still not totally clear on what is happening under the covers here,
i.e. when
and how ADAM calls netapi, etc. - even though I've been researching this
for several days now.
Thanks......
Jim
"Lee Flight" <lef@xxxxxxxxxxxxxxx> wrote in message
news:eUULM%23RHHHA.3292@xxxxxxxxxxxxxxxxxxxxxxx
Hi
what kind of ADAM users are you testing, native ADAM users?
If you enable "Audit logon eevnts" in your server security policy
you should see the Success/Failure audits for the ADAM users
in the security event log and the Failures should log the failure codes
e.g. 0xc0000234 for account lockout.
Something else to check is that the ADAM instance default behavior has
not been
changed with respct to password policies:
You can disable the enforcement of password
policy settings in ADAM by setting ADAMDisablePasswordPolicies,
a value in the attribute msDS-Other-Settings on
CN=Directory Service,CN=Windows
NT,CN=Services,CN=Configuration,CN={GUID}
to 1.
Lee Flight
"jpierson" <jpierson@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:364D0C5C-7BCB-4383-9995-F2DEDE9FC869@xxxxxxxxxxxxxxxx
I must be overlooking something real stupid.
All the docs state that ADAM will use the policies of the host
machine, but
try as I may, I can't get ADAM to lockout an account due to bad
passwords. I
have confirmed that the policy is in effect by creating a bogus
account on
the server and failing authenication enough times to lock out the
Windows
account, but I can supply bad passwords for my ADAM accounts till the
cows
come home without triggering an account lockout.
Any pearls of wisdom to point me in the right direction?
.
- Follow-Ups:
- Re: ADAM not honoring account lockout policy on Workgroup 2K3
- From: Jim Pierson
- Re: ADAM not honoring account lockout policy on Workgroup 2K3
- References:
- Re: ADAM not honoring account lockout policy on Workgroup 2K3
- From: Lee Flight
- Re: ADAM not honoring account lockout policy on Workgroup 2K3
- From: Jim Pierson
- Re: ADAM not honoring account lockout policy on Workgroup 2K3
- From: Joe Kaplan
- Re: ADAM not honoring account lockout policy on Workgroup 2K3
- From: Jim Pierson
- Re: ADAM not honoring account lockout policy on Workgroup 2K3
- Prev by Date: Re: ADAM not honoring account lockout policy on Workgroup 2K3
- Next by Date: Re: Using ADAM for authenticating non-AD users
- Previous by thread: Re: ADAM not honoring account lockout policy on Workgroup 2K3
- Next by thread: Re: ADAM not honoring account lockout policy on Workgroup 2K3
- Index(es):
Relevant Pages
|