Remote CA Connections

Mar 19, 2014 at 11:11 PM
Edited Mar 19, 2014 at 11:25 PM
With the assistance of Camelot, I have some very useful scripts.
I am now attempting to run the same script across multiple CAs, in different domains, all across my customer enterprise.

My issue: I can connect to and query my local DEV CA only when I specify the connection target of the connect-ca as ' . ' , or using the IP address. When I try to connect to the local host via a FQDN, or any other CA via a FQDN, I am unable to connect.

New-Object : Exception calling ".ctor" with "1" argument(s): "Specified Certification Authority
'<fully_qualified_server_name_here>' is unavailable."
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSPKI\Server\Connect-CertificationAuthority.ps1:13 char:4
  • New-Object PKI.CertificateServices.CertificateAuthority $CName
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
    • FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
Thanks !
Coordinator
Mar 20, 2014 at 6:40 AM
The code uses RPC DCOM port (TCP 135) to connect CA remotely.
Mar 20, 2014 at 2:57 PM
Edited Mar 20, 2014 at 4:02 PM
Thanks Camelot. That answers my original (edited) question.

However, I am unable to determine why I cannot connect to the local CA using the FQDN. I have completely disabled the firewall, so there are no port blocking issues. The error is identified above.

connect-ca fully.qualified.domain.name | get-issuedrequest ......

Looking at the server cmdlet 'Connect-CertificationAuthority', and I could be wrong here, but it look like the param for the CA-Name being passed gets over written with $ENV:COMPUTERNAME under all circumstances. I would think that there would be a conditional check to determine whether a named machine was passed as a param. If the param is empty, then it would make sense to ovewrite the passed param with the local machine name.

It would seem a [switch] would be useful, if $false then $ComputerName = $ENV:COMPUTERNAME, else $COMPUTERNAME = passed param.

But ... I might be misreading the cmdlet, and I could be completely wrong.

Please advise.
Mar 21, 2014 at 8:31 PM
A little more digging has shown that the short NetBIOS name works fine, but fully qualified names do not.

Is this by design?
Coordinator
Mar 22, 2014 at 11:38 AM
but it look like the param for the CA-Name being passed gets over written with $ENV:COMPUTERNAME under all circumstances.
nope. This means that if '-ComputerName' parameter is not specified a local computer is used. In other words, it is default value. When you specify anything in the '-ComputerName' parameter, you override default value.
A little more digging has shown that the short NetBIOS name works fine, but fully qualified names do not.
it looks like your customer has DNS issues. I checked the code against my network and Connect-CA works with both, NetBIOS and FQDN names.
Coordinator
Mar 27, 2014 at 1:47 PM
Did you resolve the issue?
Mar 27, 2014 at 2:57 PM
Thank you for the follow-up, but no ... I have not resolved the issue.

My scripts are running from a 2008 R2 server, and it appears that when the NetBIOS name of the local machine is pinged, the IPv6 loopback interface ::1 is returned, rather than the expected IPv4 formatted address.

It does appear that something goofy is happening in the environment, and I am trying to pinpoint what it is. I may be forced to find a workaround, since this my customer is a global powerhouse in their industry (believe me, you've heard of them). Getting the environment to change will be NIGH IMPOSSIBLE ...

I have not been able to get my script to connect to anything other than " . " or " ::1 " yet, not even dotted IP addresses.

Sigh ...
Coordinator
Mar 27, 2014 at 4:09 PM
Can you confirm whether these two command works for you:
$CertRequest = New-Object -ComObject CertificateAuthority.Request
$CertRequest.GetCAProperty("CAHostName\CAName",0x6,0,4,0)
$CertAdmin = New-Object -ComObject CertificateAuthority.Admin
$CertAdmin.GetCAProperty("CAHostName\CAName",0x6,0,4,0)
Replace CAHostName with actual CA host name (you can try NetBIOS and FQDN) and CAName with actual CA name (which is the CN value of the CA certificate).
Mar 31, 2014 at 8:19 PM
Edited Mar 31, 2014 at 8:49 PM
Camelot, I am able to connect to remote CAs using the commands above while specifying the "FQDN\CAName" format.

However, when I try to connect to a remote CA to process the get-caschema (to test connect/reading) command, I am getting this error:

PS C:\Users\svc-ADCSpubCRL> connect-ca "fully.qualified.domain.name" | get-caschema
New-Object : Exception calling ".ctor" with "1" argument(s): "CCertConfig::GetField: The parameter is incorrect.
0x80070057 (WIN32: 87)"
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSPKI\Server\Connect-CertificationAuthority.ps1:13 char:4
  • New-Object PKI.CertificateServices.CertificateAuthority $CName
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : InvalidOperation: (:) [New-Object], MethodInvocationException
    • FullyQualifiedErrorId : ConstructorInvokedThrowException,Microsoft.PowerShell.Commands.NewObjectCommand
I am logged into the server using a service account that has read perms on all the databases and service registries of all my remote CAs.

Also,

In my test environment, running "get-ca" correctly returns the list of CAs in the domain. In my production environment, running the command fails with the following error:

PS C:\Users\svc-ADCSpubCRL> get-ca
Exception calling "GetCA" with "2" argument(s): "There is no such object on the server.
"
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSPKI\Server\Get-CertificationAuthority.ps1:14 char:20
  • "__ComputerSet" {[PKI.CertificateServices.CertificateAuthority]::GetCA("Server ...
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    • FullyQualifiedErrorId : DirectoryServicesCOMException
running get-ca with th a filter "chq*" fails similarly.

Also, passing named arguments results in this:

PS C:\Users\svc-ADCSpubCRL> get-ca -name "chq*"
PS C:\Users\svc-ADCSpubCRL> get-ca -computername "chq*"
Exception calling "GetCA" with "2" argument(s): "There is no such object on the server.
"
At C:\Windows\system32\WindowsPowerShell\v1.0\Modules\PSPKI\Server\Get-CertificationAuthority.ps1:14 char:20
  • "__ComputerSet" {[PKI.CertificateServices.CertificateAuthority]::GetCA("Server ...
  • ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    • CategoryInfo : NotSpecified: (:) [], MethodInvocationException
    • FullyQualifiedErrorId : DirectoryServicesCOMException
I fell like I am getting close to determining where the issue is, but I need some help crossing the goal line.
Apr 1, 2014 at 7:10 PM
Ok, I have made some progress.
There were definitely some service and permission issues on the remote CAs. Those have been remediated in the larger of the two domains I am trying to use. I am still trying to remediate the other domain.

I have observed a strange occurance. When trying to cross domain boundaries (tools server in DomainA running my script, trying to talk to CA in DomainB) ... connectivity fails as noted above. Same code, same account that works when run from a machine in DomainB, isnt working from DomainA.

Up to this point, all my issues have been permissions, local group membership, and remote-registry service related issues.

I hope this will be helpful to other expriencing issues.
Coordinator
Apr 1, 2014 at 7:18 PM
Sorry, today I was a bit busy and couldn't work on this issue. But it still a bit wird, because certain errors are odd for me (for example, "There is no such object on the server") and they shouldn't appear. Tomorrow I will go though the code again to find something related.
There were definitely some service and permission issues on the remote CAs.
in the previous post you said that your service account has all required permissions?
Up to this point, all my issues have been permissions, local group membership, and remote-registry service related issues.
what is the current status? Can you connect to CA (which located in domain B) from a management computer in domain A?
Apr 1, 2014 at 8:45 PM
Camelot, I want to thank you for your attention and assistance through all this. You are a true rockstar!

Current Status:

Script running from Server_A in Domain_A against CAs in Domain_A : success
Script running from Server_1 in Domain_B against CAs in Domain_A : Failure
Script running from Server_1 in Domain_B against CAs in Domain_B : Failure

I am looking at the CAs in Domain_B:
CA1 = Windows Server 2003
remote registry service [running, read access confirmed(remotely)]
svc-acct in local administrators group [by way of another group, check]
CA DB Permissions for svc-acct [read,manage ca]
remote connection from tools server on port 135 [confirmed]
PoSH 2.0 installed, PSPKi 2.8, local tests:
    get-ca [fails, 'exception calling GetCA with 2 args: "there is no such object on the server" '], 
    connect-ca . | get-caschema [fails, 'New-Object: Exception calling ".ctor with 1 arg: "GetCertConfig::GetField: parameter incorrect. 0x80070057"'  ]
CA2 = Windows Server 2008 R2
remote registry [running, read access confirmed(remotely)]
svc-acct in local administrators group [by way of another group, check]
CA DB Permissions for svc-acct [read,manage ca]
remote connection from tools server on port 135 [confirmed]
PoSH 2.0 installed, PSPKI 2.8, Local tests:
    get-ca [fails, 'exception calling GetCA with 2 args: "there is no such object on the server" '], 
    connect-ca . | get-caschema [fails, 'New-Object: Exception calling ".ctor with 1 arg: "GetCertConfig::GetField: parameter incorrect. 0x80070057" (WIN32: 87)'  ]
Server_1 in problematic domain:
PoSH 4.0, PSPKI 2.8
PoSH 2.0 installed, PSPKI 2.8, Local tests:
    get-ca [fails, 'exception calling GetCA with 2 args: "there is no such object on the server" '], 
    connect-ca [netbios/fqdn of known CA] | get-caschema [fails, New-Object : Exception calling ".ctor" with "1" argument(s): "There is no such object on the server. ]
Apr 1, 2014 at 9:10 PM
Edited Apr 1, 2014 at 9:41 PM
Another piece of information:

From Server_1 in Domain_B, issuing the manual commands for [$certrequest and $certadmin] while specifying the known CA and CN names of the two CAs in Domain_B, both command sets will complete successfully.

From Server_1 in Domain_B, issuing the manual commands for [$certrequest and $certadmin] while specifying the known CA and CN names of two of the CAs in Domain_A, both command sets complete successfully.
Apr 14, 2014 at 9:41 PM
Edited Apr 14, 2014 at 10:12 PM
I was doing some more research, going nuts trying to get my totally functional script from domain A working in domain B .... when I found this article:

http://pspki.codeplex.com/discussions/361720

It turns out this is the EXACT issue I am having in problematic Domain B.

The discussion above sites a work order, but the link refering to the work order has no meaningful target behind it.

Do you have any recomendations as to how I can impliment a work-around for trying to query CAs at the forest level, rather than at the domain level ?

Would I be able to modify some of the files in the module for forest-level CAs, and then put a little extra logic in my script so that if CAs in domain A use:

connect-ca $certsrv | get-issuedcertificate [ ... ]

and CAs in domain B (at the forest level) use:

connect-forest-ca $certsrv | get-forest-issuedcertificates [ ... ]

etc ??


Thanks !
Coordinator
Apr 15, 2014 at 5:13 AM
Do you have any recomendations as to how I can impliment a work-around for trying to query CAs at the forest level, rather than at the domain level ?
what type is your CA? Enterprise CAs are registered in the configuration naming context and are forest-wide services. The code looks for any Enterprise CA in the forest. There is no domain-level lookup. Enterprise CAs are retrieved by calling Get-CertificationAuthority command.
Standalone CAs are not registered anywhere in the Active Directory, so the only way to reach it is to use Connect-CertificationAuthority command.
Coordinator
Apr 15, 2014 at 5:20 AM
Can you submit stack trace from the command?
connect-ca $certsrv
$error[0].exception.innerexception.stacktrace