greycorbel / sidcloner Goto Github PK

Currently migrating SIDs for ~8000 users and each user takes about 40 to process with copy-sid function then after running the script for nearly 9 hours every user processed produces the following error:

ErrorDetail : System.ComponentModel.Win32Exception (0x80004005): Inappropriate authentication
at GreyCorbel.SidCloner.CloneSid(String sourceIdentity, String targetIdentity)
at GreyCorbel.SidCloner.ProcessRecord()
Result : Error
TargetPrincipal : targetUser
SourcePrincipal : sourceUser

Stopping and starting the script again straight away does not stop the error. Leave the script stopped for 30 mins start again and users start to process without error.

This is being used with MIM 2016 and Granfeldt PowerShell Management Agent with copy-sid being called in the Export.ps1.

Any idea why this would be occuring?

I've compiled the solution using Visual Studio. Now a DLL-file is created. I've put it in to the System32-folder on a Domain controller. When I try to do the reflection with PowerShell, I get this result:

PS C:\Windows\system32> [System.Reflection.Assembly]::LoadFile("C:\Windows\System32\SIDCloner.dll")
Exception calling "LoadFile" with "1" argument(s): "Could not load file or assembly 'SIDCloner.dll' or one of its dependencies. is not a valid Win32 application. (Exception from HRESULT: 0x800700C1)"
At line:1 char:1

• [System.Reflection.Assembly]::LoadFile("C:\Windows\System32\SIDCloner ...

•   + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : BadImageFormatException
  
  
  

Am I missing dependencies, is something wrong with the settings of Visual Studio?
What am i missing?

Cheers

I have used sidcloner many times, but in one customer environment I'm getting access denied
I have triple checked all the requirements,
Trusts in place and working
Auditing enabled in source and target
TcpipClientSupport set in source
Migrate SidHistory set at the top of directory in the target.
I have also noted that there are no event logs created in the target when the access denied is generated.
I ran port query to check for blocked ports and I do see a problem with UDP 137, to you think that could be related?
I sure its environmental but I'm not sure where else to look.

Thanks
Dan