none
ADMT3.2 - PES - Unable to establish a session with the Password Export Server - accounts are already admins RRS feed

  • Question

  • We have a 2-way, transitive, forest-wide authentication, cross-forest trust between::

    2003 single-domain forest - SourceDomain.local - - 2003 domain &forest functional levels

    2008r2 forest root containing one live domain - TargetDomain.TargetForest.local - - 2008r2 domain & forest functional levels

    ADMT3.2 setup on GC-DC.TargetDomain.TargetForest.local and a PES key was generated there

    PES service installed on PDC.SourceDomain.local, service starts ok using TargetDomain\PES_account

    TargetDomain\PES_account is configured to "Logon as a Service" via SourceDomain.local GPO 'Default DC Policy'

    TargetDomain\PES_account is a member of TargetDomain\Migrators, which is a member of TargetDomain\Administrators

    TargetDomain\PES_account is also a member of TargetDomain\Domain Admins

    - I have confirmed that TargetDomain\PES_account can change passwords on user accounts in TargetDomain

    SourceDomain\Mig is a member of SourceDomain\Enterprise Admins and has been made a member of TargetDomain\Administrators

    I log on to GC-DC.TargetDomain.TargetForest.local  as SourceDomain\Mig.

    Attempting an ADMT inter-forest user migration, password migration is failing with the long error:

    " Unable to establish a session with the Password Export Server.  Either the currently logged on user does not have sufficient permissions to call the Password Export Server or the account that the Password Export Server Service is running under does not have sufficient permissions on the target domain controller. Verify that the logged on user is a member of the Administrator group in the source domain and that the Password Export Service account can change password of user accounts in the target domain."

    I have tried this operation with several minor variations:

    Adding Targetdomain\PES_account to SourceDomain\Administrators - - changes nothing

    Adding Targetdomain\PES_account directly to TargetDomain\Domain Admins - - changes nothing

    Adding SourceDomain\Mig directly to TargetDomain\Administrators - - changes nothing

    Just in case, I have also added 'Everyone' and 'Anonymous Logon' to the Targetdomain\Pre-Win2000 Compatible Access group - - changes nothing

    I have worked through the ADMT3.2 guide, also the PES checklist from ada pan @onlinemicrosoftcom  and Jorge's thoughts on ADMT from blogs.dirteam.com.   Most proposed resolutions deal with ensuring the PES service account in SourceDomain is an admin in TargetDomain, and ensuring the ADMT service is used by a migration account that is admin in both domains.   I have done this already.

    Is it possible that the PES key is aware of the account used to generate it on the ADMT platform in TargetDomain ?

    I ran   ADMT KEY /option:create /sourcedomain:"source domain" /keyfile:"key file path"

    on the  ADMT platform [GC-DC.TargetDomain.TargetForest.local]  but used my standard elevated account, not the migration account.... could that make a difference ?

    Any further help would be most welcome !


    Ignite a fire and a man is warm for a night: ignite a man, and he is warm for the rest of his life.
    Wednesday, July 21, 2010 9:29 AM

Answers

  • Success update !

    A new PES key was generated under the credentials of my TargetDomain migration account, and PES service was reinstalled on PDC.SourceDomain - - no improvement.

    Contrary to the MS ADMT3.2 documentation [p65] we changed the PES service account credentials from Targetdomain\PES_account  to  SourceDomain\Mig

    I can now successfully perform password migration within ADMT3.2 User Migration... using either  Targetdomain\PES_account  or  SourceDomain\Mig  as the account running ADMT on ADMT platform [GC-DC.TargetDomain.TargetForest.local]

    The only outstanding question is WHY ?

     - Why is the MS documentation not tallying with experience ?

     - why has no one else explicitly blogged / newsgrouped this config ?

    Ah well - running PES under a Source admin acocunt seems to work.

    regards


    Ignite a fire and a man is warm for a night: ignite a man, and he is warm for the rest of his life.
    Tuesday, September 7, 2010 2:39 PM

All replies

  • Verify the permission in source and target domain.  Please refer to the following blog:

    http://portal.sivarajan.com/2010/04/admt-service-account-permission-and.html

     

     


    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX http://blogs.sivarajan.com/ http://publications.sivarajan.com/ This posting is provided "AS IS" with no warranties, and confers no rights.
    Wednesday, July 21, 2010 4:04 PM
  • Any update on the issue?  Please let us know if you need more info.
    Santhosh Sivarajan | MCTS, MCSE (W2K3/W2K/NT4), MCSA (W2K3/W2K/MSG), CCNA, Network+ Houston, TX http://blogs.sivarajan.com/ http://publications.sivarajan.com/ This posting is provided "AS IS" with no warranties, and confers no rights.
    Sunday, July 25, 2010 3:22 PM
  • Santhosh - thanks for responding

    I should have name-checked your thoughts in my list of 'already gone through that'..... Unfortunately, as my notes above indicate, I have already verified the permissions of the migration account we must use, in both domains.

    The ADMT guide does not define any elevated permissions required to run the PES service.   Do you mean to suggest that the PES service should be run on SourceDomain.Local under the credentials of the migration account ?

    As a third party runs SourceDomain.Local I am not in a position to request that a TargetDomain migration account be made a member of SourceDomain.Local\Administrators;  hence our situation where SourceDomain\Mig is a TargetDomain admin.

    Is that situation a show stopper ?

    cheers

    Nick


    Ignite a fire and a man is warm for a night: ignite a man, and he is warm for the rest of his life.
    Monday, July 26, 2010 8:28 AM
  • Ok Santhosh - We have simplified the situation with our 2003-->2008R2 inter-forest migration, but are still getting the same issue:

    PES service installed on PDC.SourceDomain.local, service starts ok using TargetDomain\PES_account

    TargetDomain\PES_account is configured to "Logon as a Service" via SourceDomain.local GPO 'Default DC Policy'

    TargetDomain\PES_account is a member of TargetDomain\Administrators and TargetDomain\Domain Admins.   TargetDomain\PES_account is a member of SourceDomain\Administrators

    - I have confirmed that TargetDomain\PES_account can logon locally to SourceDC and TargetDC and change passwords on user accounts in SourceDomain and in TargetDomain.

    I have logged onto MigrationDC.TargetDomain.local using that account, and attempted to migrate user from SourceDomain - including password migration.   

    I still get the same error:   " Unable to establish a session with the Password Export Server..."

    I observe that the SourceDomainDC logs a Kerberos Event #7 at the moment of configuring password migration -

    The kerberos subsystem encountered a PAC verification failure. This indicates that the PAC from the client PES_account in realm Target.FOREST.LOCAL had a PAC which failed to verify or was modified.

    If I purge my KDC cache on MigrationDC.TargetDomain.local and then restart ADMT3.2 then four new tickets are requested immediately, and a further SPN ticket is requested moments later as I confirm the ADMT source and Target DCs.

    I still get the same error:   " Unable to establish a session with the Password Export Server..."

    SO - the only outstanding possible deviation from documented best practice [and your blog reccommendations] is that the PESkey was not generated under the credentials of the PES service account, TargetDomain\PES_account  -  a different TargetDomain\Admin account was used for that.

    Is it possible that the PES key is aware of the account used to generate it on the ADMT platform in TargetDomain ?

    Does anyone have any handy ideas ?

    Cheers

    Nick


    Ignite a fire and a man is warm for a night: ignite a man, and he is warm for the rest of his life.
    Tuesday, August 31, 2010 1:25 PM
  • Success update !

    A new PES key was generated under the credentials of my TargetDomain migration account, and PES service was reinstalled on PDC.SourceDomain - - no improvement.

    Contrary to the MS ADMT3.2 documentation [p65] we changed the PES service account credentials from Targetdomain\PES_account  to  SourceDomain\Mig

    I can now successfully perform password migration within ADMT3.2 User Migration... using either  Targetdomain\PES_account  or  SourceDomain\Mig  as the account running ADMT on ADMT platform [GC-DC.TargetDomain.TargetForest.local]

    The only outstanding question is WHY ?

     - Why is the MS documentation not tallying with experience ?

     - why has no one else explicitly blogged / newsgrouped this config ?

    Ah well - running PES under a Source admin acocunt seems to work.

    regards


    Ignite a fire and a man is warm for a night: ignite a man, and he is warm for the rest of his life.
    Tuesday, September 7, 2010 2:39 PM
  • I think this is a Bug in ADMT. The way to reproduce

    Target Forest

    • Domain target.argon.pro - created univ group target\Migrators, created User target\Migr-src
    • Domain child.target.argon.pro - created univ group child\Migrators, created User child\Migr-src

    Source Forest

    • Domain source.argon.pro - added to Builtin\administrators group these groups target\Migrators, child\Migrators

    Than I log to Source DC with eather "target\Migr-src" or "child\Migr-src" user account, a havo local admin rights.

    But if I configure to run PES as "child\Migr-src" users, i got message

    Unable to establish a session with the password export server. Either the currently logged on user does not have sufficient permissions to call the Password Export Server or the account that the Password Export Server Service is running under does not have sufficient permissions on the target domain controller. Verify that the logged on user is a member of the Administrators group in the source domain and that the Password Export Server Service account can change passwords of user accounts in the target domain.

    If I configure to run PES as "target\Migr-src" users, all is OK.

    From ACL point of view, both accounts "target\Migr-src" and "child\Migr-src" are identical.


    MCITP: EA, EMA, LSA, VA; MCSA
    Monday, October 3, 2011 1:16 PM
  • I found this worked but I also found out that when I ran ADMT as the targetdomain\pes_account it worked as well.

    I was logging into ADMT server as normal domain admin account and then just running ADMT 'as administrator'.  When I chose run as a different user and ran as the targetdomain\pes_account  it worked as mentioned in the MS documentation.

    Not sure if that is clearly stated in the documentation but you need to run the ADMT software as the same user as you have the password export server running.

    Thursday, January 18, 2018 5:36 AM