Active directory and password reseting



  • We have a 3-tier software architecture. The Middle tier runs as a windows service, and is in the same domain as the server. The client can be in any location. The client and the MT are written in C# and use WCF for connections.

    What a client has run into is that when a user from Domain A connects to the MT in Domain B, if the password for the account is expired in domain B that connection is rejected outright by the domain.

    What is the best way to allow a user from domain A to change their password in domain B after it has already expired?

    I currently have a hacked solution that works flawlessly in our test environment, but only works about 50% of the time in theirs, so I am looking for ideas. There is no rush, this was drop everything urgent last year, and we just learned yesterday that they finally got around to testing it.

    fucking hate customers.



  • Are you looking for an out-of-the-AD-box way to do it (in which case I can't help you) or to write some code of your own to handle the reset?
    If the latter, we use ADSI to do the actual reset of the password, unlock the account and set "user must change password at next logon", then the code sends that user's email address a note of the new (rando-spoofed) password.

    Yes, a user could play some havoc by resetting someone else's password, but we do at least check that the password is expired before letting the above go ahead.

    Or use SAML and ADFS, if you're happy to wait 3 years for your network/Windows team to figure out how to migrate to it...



  • We had a similar issue where users attempting to retrieve Exchange emails on their smartphones would fail if the AD password was expired. The smartphones had no method of handling the dialog from the AD server to enter a change password - it simply didn't exist.

    Workaround: instructed users to VPN in or log onto a PC directly in the domain, change their password, then update the password in the smartphone email app.



  • Since this Customer is using certs for authentication, when the connections fails we use a backdoor info request in our application to ask the MT if this users password has expired. If it comes back as true, the MT resets the users password expiration date and sets the "new password on logon" flag to true.

    We than restart the login on the client application and allow them to reset their password with some special code.

    The issue is that this only seems to work about 50% of the time at the Customer location.



  • I gave this customer a list of 5 things they could do to solve this problem, that was #1 on the list. Number 5 was, we write custom code that compromises security so that you can be lazy gits.

    Surprise, the customer chose option #5.



  • @Dragoon said:

    The issue is that this only seems to work about 50% of the time at the Customer location.

    Ah... Active Directory propagation delays? We have a relatively small domain (around 20 DCs with decent links) but it can still take a minute or two for the supposedly realtime password resets to propagate....

    This can be improved if you can identify the DC that they are likely to authenticate to (we can, via the user's location and a fixed map of countries to DCs) and then ADSI the change against the nearest DC. It's not massively scientific but it's more reliable since we kludged this in.



  • @skotl said:

    Ah... Active Directory propagation delays?

    That is sorta where I have been leaning. The person that I have been dealing with at the customer site knows nothing about AD, and I know very little, so it has been a slow process.



  • @Dragoon said:

    That is sorta where I have been leaning. The person that I have been dealing with at the customer site knows nothing about AD, and I know very little, so it has been a slow process.

    @Dragoon said:

    only works about 50% of the time

    Uhhh... it's not the same users that makes the 50% of the time, is it? You can't use ADSI to reset the password of a domain admin so I wonder if your customer has "fixed" some permission problems by making half of his users domain admins...?



  • We use an admin user in the MT to change the users password. It will work the first time, and fail for the next X (not sure, it was late and as I said, the person I am working with doesnt know AD at all) number of minutes and than allow that admin user to change another users password.


  • Discourse touched me in a no-no place

    @Dragoon said:

    Surprise, the customer chose option #5.

    And by "surprise," I mean "completely unsurprisingly!"


Log in to reply