Re: LDAP bind allowing old password for 1 hour

My suggestion regarding Kerberos actually does apply to LDAP binds. When
you use Secure authentication in ADSI, it will use the Windows Negotiate
auth package under the hood to authenticate the user. Negotiate selects
between using either Kerberos or NTLM to do the actual authentication of the
user during the LDAP bind.

If you can get Negotiate to user Kerberos authentication in your bind
operation instead of NTLM, this problem should go away. As such, it is a
potential fix.

The thing to do is to figure out why the code is using NTLM instead of
Kerberos in the first place since Kerberos is the default and to try to see
if it can be changed to make it use Kerberos. A couple of things come to
mind:
- The client machine must be domain joined to use Kerberos
- If server information is specified for the domain controller when doing
the LDAP bind, you must use a NetBIOS or DNS name for the domain controller
- You must also specify the username format in a Kerberos compatible way

Is the code you showed the code you are actually using for this SSO solution
or is it just a sample that repros the problem? In general, ADSI is not
designed for doing LDAP authentication and has a number of serious
scalability issues when used for this purpose. The ADSI documentation
mentions this.

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
--
"AlanAlbany" <AlanAlbany@xxxxxxxxxxxxx> wrote in message
news:986FB174-18E8-43C0-810D-2EDE31C9059C@xxxxxxxxxxxxxxxx
Hi,
The domain controller is running Windows 2003 with SP1. We tried setting
the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\OldPasswordAllowedPe
riod registry value to zero as you suggested but that did not make any
difference to the observed behaviour (either before or after rebooting the
domain controller). My understanding from KB 906305 is that the registry
key
value is the time in minutes that the old password is still valid for NTLM
authentication (with a default of 60 minutes) thus setting it to 1 should
have reduced the time from one hour to 1 minute. It seems that an LDAP
bind
as in the test code I posted in my original post is not affected by this
registry setting. Note this code is passing the username and password in
the
bind request (in a production environment this would need to be over
Secure
LDAP to avoid a plaintext password being sniffable). What I am looking
for
is a solution for this case, not for NTLM or Kerberous authentication
alternatives.
Regards,
Alan

"Jian-Ping Zhu [MSFT]" wrote:

Hello,

Thank you for your post.

Based on my research, to resolve this old password not expiring issue,
you
need to defining the following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\OldPasswordAllowedPe
riod as a DWORD with the value of 0.

As you mentioned in your email that you had changed this value to 1, so
please try changing this value to 0 and have another test to see whether
this will make any difference.

Moreover, as KB 906305 applies only to Windows Server 2003 with SP1,
please
ensure you have installed SP1 on your server before doing the test.

Thanks and I look forward to hearing from you soon.

Sincerely,
Neo Zhu,
Microsoft Online Support
Microsoft Global Technical Support Center

Get Secure! - www.microsoft.com/security
=====================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
=====================================================
This posting is provided "AS IS" with no warranties, and confers no
rights.

--------------------
| From: "AlanAlbany" <alanAlbany@xxxxxxxxxxxxx>
| Subject: LDAP bind allowing old password for 1 hour
| Date: Thu, 22 May 2008 11:58:30 +0800
| Lines: 54
| X-Priority: 3
| X-MSMail-Priority: Normal
| X-Newsreader: Microsoft Outlook Express 6.00.2900.3138
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
| X-RFC2646: Format=Flowed; Original
| Message-ID: <OdADbA8uIHA.748@xxxxxxxxxxxxxxxxxxxx>
| Newsgroups: microsoft.public.windows.server.active_directory
| NNTP-Posting-Host: adm332.admin.uwa.edu.au 130.95.230.180
| Path: TK2MSFTNGHUB02.phx.gbl!TK2MSFTNGP01.phx.gbl!TK2MSFTNGP05.phx.gbl
| Xref: TK2MSFTNGHUB02.phx.gbl
microsoft.public.windows.server.active_directory:42624
| X-Tomcat-NG: microsoft.public.windows.server.active_directory
|
| We are implementing a Single Sign On (SSO) solution that is using LDAP
bind
| to an Active Directory authentication domain as its means of
authenticating
| a user. We have discovered that a SSO user can autheticate with their
old
| password for one hour after the password has been changed. Other means
of
| authentication to the authenication domain are not allowing this one
hour
| grace period. Since adminstratively changing the password is our method
of
| locking out an account, this one hour grace period is not acceptable.
Is
| there a way of reducing it similar to the registry change given in
KB906305
| for a similar issue with NTLM authentication? We have tried making the
| registry change in KB906305 by defining
|
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\OldPasswordAllowedPe
riod
| as a DWORD with the value of 1 but the LDAP bind with the old password
is
| still working for up to one hour (even after a reboot of the domain
| controller). (Note we are testing using a domain with a single domain
| controller so replication delays between domain controllers can be
ruled
| out.) The following is a test VBscript that can be used to replicate
the
| problem once customised to the domain being used for testing.
|
| [CODE]
| const MyDomainFull = "ADserver.ad.com"
| set MyRootDSE = GetObject("LDAP://"; & MyDomainFull & "/RootDSE")
|
| MyRootDN = MyRootDSE.Get("defaultNamingContext")
|
| Set MyConn = CreateObject("ADODB.Connection")
| MyConn.Provider = "ADsDSOObject"
| MyConn.Properties("User ID") =
"CN=MyUser,OU=users,DC=ADserver,DC=ad,DC=com"
| MyConn.Properties("Password") = "MyPwd"
| MyConn.open "ADSI"
|
| MyLDAPStr = _
| "<LDAP://"; & MyDomainFull & "/ou=users," & MyRootDN & ">;" & _
| "(&(objectCategory=person)(objectClass=user)(cn=MyUser))" & _
| ";cn,mail;subtree"
|
| Set MyRS = MyConn.Execute(MyLDAPStr)
|
| If Not MyRS.EOF Then
| wscript.echo "Not end of file"
| MyMail = MyRS.Fields("mail")
| wscript.echo MyMail
| wscript.echo MyRS.Fields("cn")
| Else
| wscript.echo "- record not found in AD"
| End If
|
| MyRS.Close
| MyConn.Close
|
| Wscript.Quit
| [/CODE]
|
|
|
|




.

Relevant Pages

  • Re: Kerberos machine authentication - apparent authentication fail
    ... Kerberos result when I hardwired a laptop to a switch port. ... to authenticate with K on reboot AND authentication appears to take place ... > denied access until you can authenticate to a domain controller as a user. ... > You should have logging of account logon events enabled in Domain Controller ...
    (microsoft.public.windows.server.security)
  • Re: Kerberos machine authentication - apparent authentication failures
    ... When you joined your computer to the domain your wireless network card was ... denied access until you can authenticate to a domain controller as a user. ... While kerberos is the default authentication protocol of choice, ...
    (microsoft.public.windows.server.security)
  • Re: NTLM and Kerberos
    ... I would have to open port 88 to my Domain Controller? ... How would IE know which server is the Domain Controller (my home computer is ... Kerberos requires the user to obtain a Kerberos Service Ticket for the ... even attempt Kerberos authentication for sites in the Internet zone. ...
    (microsoft.public.inetserver.iis.security)
  • RE: LDAP bind allowing old password for 1 hour
    ... The domain controller is running Windows 2003 with SP1. ... My understanding from KB 906305 is that the registry key ... It seems that an LDAP bind ... is a solution for this case, not for NTLM or Kerberous authentication ...
    (microsoft.public.windows.server.active_directory)
  • Re: LDAP bind() versus Kerberos authentication (performance perspective)
    ... of using Kerberos authentication instead of LDAP bind() for authentication ... You'll have a hard time finding a server slow enough to have difficulty ... doing that authentication load using Kerberos. ...
    (comp.protocols.kerberos)
Quantcast