none
Cannot Change Passwords via UAG RRS feed

  • Question

  • Users of our system are unable to change their passwords via UAG.  The user experience is similar to that described in http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/e38eb1e0-df39-484a-a86a-63f4904087e4, but the errors in the logs are different.

    In our case, the error is "The error code is Configuration information could not be read from the domain controller, either because the machine is unavaialble, or access has been denied".

    I've sat there with network traces to see if I can figure out what is going on.  I see login attempts using the user's account, all of which appear to be successful.  I have verified that the account that is configured in the UAG authentication server source has been granted Change Password permission on the user account as well as verified that Everyone and Self have the same permission.

    Is there something that I'm missing here?


    /Jeff Huston
    Tuesday, November 2, 2010 5:53 PM

Answers

  • Hi Jeff,

    Password change use LDAPS, so you need to check:

    • Your domain controllers have SSL certificates installed and your UAG server trusts the certificate issuer.
    • Your AD repository is defined using FQDNs and secure ports.

    TMG has similar generic requirements as discussed here: http://technet.microsoft.com/en-us/library/cc984426.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, November 2, 2010 8:19 PM
    Moderator
  • Okay, so that put me on the right track.  Did some investigating and found out that the DCs were issued certificates from a CA server that no longer exists.  The UAG server wasn't configured to trust certificates issued by that old CA, hence the issue.

    I reissued certs to the DCs (* see below for that story) and retested.  All is working now.  Thanks for the help!

    ---

    Okay, so reissuing certs on the DCs was a pain.  Prior to my arrival, the DCs were set up as Server Core.  While totally effective as domain controllers, this leaves something to be desired for server management of some items (such as certificates).  So, here's what I did (noted for future reference of others):

    • Ran the certutil -viewdelstore my command and deleted each DomainController certificate that existed.
    • Using regedit, I deleted the HKLM\Software\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache key.
    • I forced a GP update (gpupdate /target:computer /force) to cause it to determine that it needed to auto-enroll and there were no existing certificates.

    After a minute or two, the new certificate was in place and I was good to go.


    /Jeff Huston
    • Marked as answer by Jeff Huston Wednesday, November 3, 2010 12:34 AM
    Wednesday, November 3, 2010 12:34 AM

All replies

  • Hi Jeff,

    Password change use LDAPS, so you need to check:

    • Your domain controllers have SSL certificates installed and your UAG server trusts the certificate issuer.
    • Your AD repository is defined using FQDNs and secure ports.

    TMG has similar generic requirements as discussed here: http://technet.microsoft.com/en-us/library/cc984426.aspx

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, November 2, 2010 8:19 PM
    Moderator
  • Okay, so that put me on the right track.  Did some investigating and found out that the DCs were issued certificates from a CA server that no longer exists.  The UAG server wasn't configured to trust certificates issued by that old CA, hence the issue.

    I reissued certs to the DCs (* see below for that story) and retested.  All is working now.  Thanks for the help!

    ---

    Okay, so reissuing certs on the DCs was a pain.  Prior to my arrival, the DCs were set up as Server Core.  While totally effective as domain controllers, this leaves something to be desired for server management of some items (such as certificates).  So, here's what I did (noted for future reference of others):

    • Ran the certutil -viewdelstore my command and deleted each DomainController certificate that existed.
    • Using regedit, I deleted the HKLM\Software\Microsoft\Cryptography\AutoEnrollment\AEDirectoryCache key.
    • I forced a GP update (gpupdate /target:computer /force) to cause it to determine that it needed to auto-enroll and there were no existing certificates.

    After a minute or two, the new certificate was in place and I was good to go.


    /Jeff Huston
    • Marked as answer by Jeff Huston Wednesday, November 3, 2010 12:34 AM
    Wednesday, November 3, 2010 12:34 AM
  • certutil -pulse is also useful...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, November 3, 2010 8:20 AM
    Moderator