TPAM Service Account Access Denied Error with 2019 Domain Controller

I am a domain administrator, not a TPAM administrator, but needed to run this by you all as best I could to see if anyone has had this issue or has a solution?

Our TPAM service account is receiving an Access Denied error when trying to change an account's password and this happens when pointing to one of our new Windows Server 2019 domain controllers.  We have been replacing our 2012R2 with 2019 and we are down to the last 2012R2.  This Access Denied error occurs when they point TPAM to the new DCs but it works fine with the last 2012R2.  We have verified all the individual security permissions are still there from the initial stand-up a few years ago so what changed with the new DCs?  Also, IF the service account were placed in the Administrators group, it works fine.

We have ruled out GPOs by running a test with a 2019 DC in a GPO blocked OU but the problem persists.  Also compared the Local Security Policies on one of each, 2012R2 and 2019, and didn't find anything that would cause this access issue.  Also checked UAC when we found a difference in settings but again, no luck.  

We are at the point now of having to build a new server ourselves with the 2019 ISO and not the template our VMware team used.

I suspect something changed with Windows Server 2019 as far as maybe a new permission that we need to give to the TPAM service account.  Any thoughts, ideas, or solutions would be greatly appreciated!

Parents
  • Afternoon

    So far you have focused on the Directory side of things. I think you need to look at things now from the TPAM side to see if you can get any clues.

    Do you have access to the TPAM to check the logs and be able to run the built in tests?  You would need the TPAM Administrator role on the /TPAM web I/F to do this. If you have access the system test would be the first one  I would go for as this check functional account authentication and connectivity.

    What is the TPAM version you are running?

    Can you authenticate to the Domain from a PC using the Functional/Service account?

    Where is the account you are trying to manage? is it a local account on a member server that you are managing with a Domain Functional/Service account or a Domain account?

    Are the new 2019 servers part of the same domain as the 2012 servers?

    What permissions have you given the TPAM Functional/Service account? Minimum permissions are:

    Object type: User Objects
    - Reset Password
    - Read and write account restrictions
    - Read lockout time
    - Write lockout time
    KB208447 and KB 94966 have more info.

    Also have you checked the Knowledge base on the One Identity web site to see if there is anything there that may help with the error you are getting.

    Hope this helps

    Best regards

    Tim



  • TPAM says when they change the DC IP they are using, they run the test and it is successful.  They then check password on the tpam service account and it comes back successful.  It fails when they try to reset the password.

    Version:  2.5.921.0306

    The service account authenticates with the domain when check password is done.

  • First let us make sure that we are talking about the same account here. In TPAM speak the account that manages password is refered to as a "Functional account".

    So is the service account you are referring to (as I have assumed) .the TPAM functional account?

    And is it the password for the functional account, that you are trying to re-set the password on, when you say the password reset failed?

    or

    Are they/you trying to change the password of an account on another system with the Functional account when you see the change failed message?

    When the TPAM team hit the Change Password button what account on what system are they testing and what error is reported in the Password change log?

    Next It would be good to know where in the TPAM configuration the TPAM team are changing the IP of the DC. Best practice would normally be to configure a FQDN rather than the IP of a specific DC for resilience.

    Not the latest TPAM code release but one that has been around since the release or server 2019. 2.5.925 is the latest.. At this stage I don't think updating would help but if you need to raise a case with One Identity support you may need to.

    Best regards

    Tim

  • Tim,

    Replies from the TPAM folks --

    First let us make sure that we are talking about the same account here. In TPAM speak the account that manages password is referred to as a "Functional account".

     Yes

    So is the service account you are referring to (as I have assumed) .the TPAM functional account? 

    Yes

    And is it the password for the functional account, that you are trying to re-set the password on, when you say the password reset failed?

    Answer:   No, the functional account needs the ability to reset it owns password and the passwords of the other admin accounts.   If the functional account fail to reset it's own pwd, then the admins will get a post release error.  TPAM will keep trying to reset the pwd daily and will fail until the functional account is working.

     or

     Are they/you trying to change the password of an account on another system with the Functional account when you see the change failed message?

     Answer: No, the accounts are all on the same system.

     

    When the TPAM team hit the Change Password button what account on what system are they testing and what error is reported in the Password change log?

    Answer: Testing with the functional account on the system with the other admin accounts.  The error is the one I have been sending snapshots of.

     

    Next It would be good to know where in the TPAM configuration the TPAM team are changing the IP of the DC. Best practice would normally be to configure a FQDN rather than the IP of a specific DC for resilience.

     Answer: The IP is changed on the system, we can try the FQDN.

     

    Not the latest TPAM code release but one that has been around since the release or server 2019. 2.5.925 is the latest.. At this stage I don't think updating would help but if you need to raise a case with One Identity support you may need to.

    Answer:  The version is 2.5.921.0306, which is the latest update we received.  There is no longer support from One Identity so I know a case cannot be raised with them.

  • first 2.5.923 is available on the One Identity site for download. I updated a client just last week to this revision.

    From the One Identity site: https://support.oneidentity.com/tpam/lifecycle

    Version Full Support as of  Limited Support as of  Support Discontinued 
    2.5.923 27-Feb-2020 10-Aug-2020 1-Feb-2022
    2.5.922 12-Aug-2019 10-Aug-2020 1-Feb-2022
    2.5.921 10-Aug-2018 10-Aug-2020 1-Feb-2022

    So IF you have a valid support contract in place then support IS still available all be it Limited.

    Limited support is defined as:

    Limited Support

    • Support is available for this release/version, and we will use best efforts to provide known workarounds or fixes.
    • No new code fixes will be generated except under extreme circumstances and at our discretion.
    • Enhancement requests are not accepted.
    • You are encouraged to plan an upgrade to a release/version on "Full Support".
    • Release/version is available for download from the Support Portal.

    So getting back to your issue.

    It is difficult to provide much more assistance at this stage as I have no visibility of the TPAM configuration or the logs and screen scrapes that have been supplied.

    Without a view of the logs and configuration it is difficult to see what is going on from here.

    Start by Not assuming anything about the issue - Like it has to be a 2019 domain issue Something else could be at the route of the problem and your upgrade to 2019 has just highlighted it.

    I would review the TPAM solution and how it is configured, how it interacts with the rest of the infrastructure, positions of firewalls, the systems + account being managed etc.

    Try to break down the problem into smaller simpler blocks to try to figure out just where things are going wrong.

    You could get your TPAM team to create a new system with a WINAD platform type in TPAM from scratch. Providing the functional account details with the required domain name and net bios name but initially not enabling auto rotation of the functional account. Test this and make sure it is working.

    Then add one specific test account to to the new WinAD system and see if TPAM can manage that account. You could then add a test account on a member server and see if TPAM can manage the passwords for this account.

    Then if this is working try enabling the password rotation on the functional account.

    You can also engage with the One Identity Professional services team who will be able to assist you with this issue.

    Although this will not be covered under your normal Support contract it may be a cost effective way to help resolve things quickly. They would be able to review the TPAM configuration against known best practices, perform a health check on the solution and assist if location the issue

    I do not know where you are based but you could arrange a remote session to look at the issue with somebody from the One Identity TPAM PS team, yourself and your TPAM admin.

    Best regards

    Tim

Reply
  • first 2.5.923 is available on the One Identity site for download. I updated a client just last week to this revision.

    From the One Identity site: https://support.oneidentity.com/tpam/lifecycle

    Version Full Support as of  Limited Support as of  Support Discontinued 
    2.5.923 27-Feb-2020 10-Aug-2020 1-Feb-2022
    2.5.922 12-Aug-2019 10-Aug-2020 1-Feb-2022
    2.5.921 10-Aug-2018 10-Aug-2020 1-Feb-2022

    So IF you have a valid support contract in place then support IS still available all be it Limited.

    Limited support is defined as:

    Limited Support

    • Support is available for this release/version, and we will use best efforts to provide known workarounds or fixes.
    • No new code fixes will be generated except under extreme circumstances and at our discretion.
    • Enhancement requests are not accepted.
    • You are encouraged to plan an upgrade to a release/version on "Full Support".
    • Release/version is available for download from the Support Portal.

    So getting back to your issue.

    It is difficult to provide much more assistance at this stage as I have no visibility of the TPAM configuration or the logs and screen scrapes that have been supplied.

    Without a view of the logs and configuration it is difficult to see what is going on from here.

    Start by Not assuming anything about the issue - Like it has to be a 2019 domain issue Something else could be at the route of the problem and your upgrade to 2019 has just highlighted it.

    I would review the TPAM solution and how it is configured, how it interacts with the rest of the infrastructure, positions of firewalls, the systems + account being managed etc.

    Try to break down the problem into smaller simpler blocks to try to figure out just where things are going wrong.

    You could get your TPAM team to create a new system with a WINAD platform type in TPAM from scratch. Providing the functional account details with the required domain name and net bios name but initially not enabling auto rotation of the functional account. Test this and make sure it is working.

    Then add one specific test account to to the new WinAD system and see if TPAM can manage that account. You could then add a test account on a member server and see if TPAM can manage the passwords for this account.

    Then if this is working try enabling the password rotation on the functional account.

    You can also engage with the One Identity Professional services team who will be able to assist you with this issue.

    Although this will not be covered under your normal Support contract it may be a cost effective way to help resolve things quickly. They would be able to review the TPAM configuration against known best practices, perform a health check on the solution and assist if location the issue

    I do not know where you are based but you could arrange a remote session to look at the issue with somebody from the One Identity TPAM PS team, yourself and your TPAM admin.

    Best regards

    Tim

Children
No Data