Accessing LDAP for User/Password Authentication

Locked Accessing LDAP for User/Password Authentication

  • Thursday, May 17, 2012 5:54 PM
     
     

    I need to authenticate a user against LDAP/AD (windows 2008 r2) so I can leverage the domains password rules etc...

    I found code that will allow me to validate a users ID and Password entered into a form (using System.DirectoryServices.DirectoryEntry) but my problem is if the user enters an invalid password more that AD is configured to allow, the account gets locked out. Is there anyway around this?

    I just want to validate that a given user/password is valid against AD.


    DCODER

All Replies

  • Friday, May 18, 2012 4:48 AM
     
     Answered

    no there isn't any way around this in your code, because the lockout occurs as an action by the server. You would have to modify the server policies to disable or raise the lockout threshold to do it. after all, account lockouts become a rather meaningless security barrier if its trivial to bypass them.

    I have seen evidence before that group policy can be used to delegate a different set of account policies to differant groups of users, potentially not enforcing constraints that may be present for other operators. For instance, in one shop I worked for, normal users and junior admins could only use passwords that have not previously been used, but senior admins were not held to this constraint and could set any password, even those that violated the rules everyone else played by.

    if your organizations sysadmins can create a user that can bypass lockout thresholds, and you run your app under that account (perhaps using runas) the users could then attempt as many logins as they wanted.

    I should say though, this is all a very bad idea. it introduces vulnerabilities in your infrastructure, for what is IMO a trivial concern.

     

  • Friday, May 18, 2012 1:37 PM
     
     

    I really don't want to mess with our network policies and creating a user that can bypass lockout would not fly here. We are running PeopleSoft here and that product uses LDAP to authenticate users so they can log on using thier network logon and network password. There doesn't seem to be any issue when users enter incorrect passwords. Thier domain account does not get locked out..... hummmm.

    Thanks for your reply.


    DCODER

  • Saturday, May 19, 2012 9:51 PM
     
     

    are you saying that you have an AD, and a separate LDAP directory that Peoplesoft uses (which proxies logins to AD)? if that is the case does your code target the AD or the LDAP service?

  • Thursday, May 24, 2012 6:34 PM
     
     

    I have a feeling that PeopleSoft logs into LDAP as a static read-only user and does a lookup against it using the users domain ID and password to validate it. Is this possible? How do you perform a query against LDAP once you connect to validate a user domaind name AND password? Is that possible to do?


    DCODER

  • Friday, May 25, 2012 10:52 AM
     
     Answered

    Try http://stackoverflow.com/questions/5798598/authenticating-passwords-against-an-ldap

    AFAIK you have  basically two approach : try to log (in which case you are subject to the policies if the login fails) or get the hashed password and compare with some other values (and I have no idea about how to do the later)...

    As this is AD related and that the programming language is basically irrelevant IMO it could be better to ask in a lower level win32 api group or perhaps even low level security programming group as it would likely involve to use low level API.

    Also the current behavior seems consistent (after all it is true that the user provided a wrong password several times it seems consistent to apply then the usual security policy).

    BTW you said you need LDAP authentication because you need to "leverage rules" ? It seems rather you try to circumvent them ? Try to double check that a simpler approach such as integrated authentication doesn't fit your needs. What kind of ap is this ?


    Please always mark whatever response solved your issue so that the thread is properly marked as "Answered".