Link to home
Start Free TrialLog in
Avatar of Edwin Betancourth
Edwin BetancourthFlag for United States of America

asked on

Unable to PKI Login from second untrusted Forest

I getting the following error:

"The system cannot log you on due to the following error:  The Security database on the servers does not have a computer account for this workstation trust relationship"

I have tried disjointing and re-joining the workstation to the Domain with no sucess
Avatar of Paranormastic
Flag of United States of America image

If the two AD forests do not trust each other then there is no reason why they should accept any kind of logon from each other.  This can be done by allowing your domain's AD to trust the other domain.  Keep in mind that the smart card logon must be a valid attribute of the certificate - if you are able to log into workstations from the issuing domain then you should be in business.  If you are merely authenticating to their VPN, etc. then open up the cert and look at the key usages to determine your answer.  One last caveat is that their CRL must be publicly available so that it can be reachable from your network during logon in order to check to make sure that the certs have not been revoked.

Here is a Microsoft article that will hopefully answer your question:

The only other thing I could think of is to set up a terminal services type of setup - if you are interested in that I can provide more details.
Avatar of Edwin Betancourth


Here is more detailed description of the problem:

Here is the problem Description:


Environment Client  Windows XP SP2 + Post SP2 hotixes.


Server Environment  Two non-trusted Forest, Forest A includes a three-tiered MS CA, Forest B is configured based on the following article to allow SC PKI Logon:


Error message encountered on Smart Card PKI Logon:


"The system cannot log you on due to the following error:  The Security database on the servers does not have a computer account for this workstation trust relationship"


At first it was perceived to be an issue with SPN but disjoining and re-joining the workstation to the domain did not solve the problem.


See attached logon.cap and userevent log.  Since the authentication does not proceed once the error is encountered, winlogon and MSGina logs are being recorded.


We tested successfully PKI Authentication at the Server Level (Forest B) so we know the CA trust between both forest is working properly.

Sorry for the delayed response.  Are you still trying to get this to work, or has this been resolved already?  For some reason, the file attachments are not showing up here.

Are you having this issue from multiple workstations, or have you just tried the one?  Are they in the same domain as the servers that were working OK for this, or are they in a child domain or another domain in the same forest?  If different domains, check the active directory functional level to make sure that they are the same.  Also, check the group policies that are applied to the different OU's, if you have not already (I'm guessing you have already done this, but just putting in there in case).

Sometimes things get crazy when there are multiple GiNA's on the same box - not sure if that is the case or not, but can be if there is a smart card middleware along with citrix, entrust, netware client, or a number of other programs - the chaining order tends to be important.  Normally you want the smart card to be the first one applied under the MS GinaDLL value in the registry, then there would be a vendor-specific reference pointing to any other GiNA stubs (if any, a normal exception would be Cisco VPN client) with GiNA replacements (like the 3 apps I mentioned above) being last.  The GiNA value is stored here (not present = default MS GiNA only):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

Hopefully you have already gotten a fix for this already - if not I hope this post helps some without knowing what was in the logs.
Hello Paranormastic,

I'm still struggling with this issue.  I'm adding the logs in txt format to see in something meaningful jumps put.  Notice the Kerberos error on the "MicrosoftNetworkMonitorDUMP.txt" .  thanks to review...
I see that you using ActivIdentity for the SC product - they are generally a pretty good company.  I am guessing you are trying to SC enable you test lab against your production?  Thats pretty slick :)

ReadGPExtensions: Rsop entry point not found for (filename)
- Are you sure that GPO is being processed ok here?  One forum on this suggested to give Authenticated Users read access for the OU that the GPO is being sent through.  Found this one too that looks a bit more specific:

Don't know if that will help in the big picture, but it might.  If not, could you please respond with answers to my last post just so I have those questions cleared up in my head?
Thanks Paranormastic,

To answers your questions:

1) My two environments are strictly in a TEST environment.
2) Each enviroment is its own domain with no TRUST in between.  This is because the "Issuance" domain which contains the CA will have no trust whatsoever with the "Authentication"  Domain in PROD.
3) I only have one XP station in the LAB for testing.  If I RDP to the Authentication Domain, PKI logon works great.
4) The lab machine is a member of the authentication domain only.
Avatar of Paranormastic
Flag of United States of America image

Link to home
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Start Free Trial