Questions
Error enabling TLS from Management Agent
Hi Gents,
I'm configuring my IDB management agents, and I've noticed the following error being thrown when I try to enable TLS:
I have created a self signed cert and configured it within the interface.
For reference, I used the following command to create my cert:
New-SelfSignedCertificate -Type Custom -Provider "Microsoft RSA SChannel Cryptographic Provider" -Subject "CN=Unify.IdentityBroker" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2") -KeyUsage DigitalSignature -KeyAlgorithm RSA -KeyLength 2048 -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(5)
Answer
Additional Info:
IDB v5.2.0 Revision #2
No errors are thrown in the IDB or Event Logs.
Gateway config is default:
Weird - Curtis I got an email notification on your comment, but it's not showing here.
Confirming I do have the latest version of IDB for MIM installed - 5.1.0.1.
Adam is that patch to go in the IDB directory or under fim extensions, or both...?
Haha well got a new error from that one when trying to point the MA at the DLL:
The extensible extension returned an unsupported error.
The stack trace is:
"System.IO.FileLoadException: Could not load file or assembly 'file:///C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions\Unify.IdentityBroker.FIMAdapter.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
File name: 'file:///C:\Program Files\Microsoft Forefront Identity Manager\2010\Synchronization Service\Extensions\Unify.IdentityBroker.FIMAdapter.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
at System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
at System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark)
at System.Reflection.Assembly.LoadFrom(String assemblyFile)
Forefront Identity Manager 4.4.1459.0"
Please check if the file has zone identifier information (right click, unblock, apply).
Hah well I have no idea how you figured that out, but yes that worked.
First test of enabling TLS caused the MIM Client to hang. I traced the following error in the event log:
A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.
A google of this error indicated a possible permissions issue (among other solutions).
I made the IDB account a local admin, and restarted the service.
Shortly after restart, the CPU pegged at 100%. No idea why, nothing particularly indicative in the log.
Restarted again (stable this time) and retried the TLS option. Indicative error this time:
I'll see I if I can sort this one :)
That's one we haven't seen come through before X509ChainStatusFlags.NotValidForUsage. I can't find any information on it unfortunately though.
We'll also look at making this configurable so that additional flags can be ignored.
Looks like you may have made a mistake when you generated the certificate https://stackoverflow.com/questions/44337442/using-c-how-to-programmatically-determine-if-a-certificate-in-a-windows-certif#44338113
Yep seems like it.
This looks like a good page on this topic:
My cert has an Enhanced Key Usage of Client Authentication but not Server Authentication, that's likely what it's whinging about.
For reference, the following command create's a usable cert with a 5 year expiry. The cert also needs to be installed in the Trusted Root Certification Authority store for it to work.
This needs to be run as administrator.
New-SelfSignedCertificate -Type Custom -Provider "Microsoft RSA SChannel Cryptographic Provider" -Subject "CN=Unify.IdentityBroker" -TextExtension @("2.5.29.37={text}1.3.6.1.5.5.7.3.2,1.3.6.1.5.5.7.3.1") -CertStoreLocation "Cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(5)
Customer support service by UserEcho
Please try Unify.IdentityBroker.FIMAdapter.dll and let me know how it goes.