You can try using the windows credential manager assuming you are on Win7+. This will allow you to specify the credentials for the domain where the AF Server is. I have used this with AF and it does work.
Please try to connect using PI AF SDK, by creating a custom console application using the code snippet below:
PISystems myPISystems = new PISystems(); PISystem myPISystem = myPISystems["AFSERVERNAME"]; myPISystem.Connect(new System.Net.NetworkCredential("domainuser", "password"));
If that doesn't work, try using all different constructors for System.Net.NetworkCredential. Which exception error are you receiving? Do you see any error message on the PI AF Server?
Thanks for the reply,
I'll try it out and let you know.
Your scenario is a valid Windows authentication scenario. When troubleshooting Windows authentication problems, the best thing to do is to first reproduce the problem with as few dependencies as possible. Ideally, with Microsoft-only client and server software. There are typically at least a couple of readily available and relatively easy Microsoft-only options like file sharing and Remote Desktop (or in PI AF environments, maybe SQL Server and Tools).
From my reading of the DisableDomainCreds registry key, it seems like this should only prevent saving / persisting domain credentials -- even into Windows Credential Manager -- not simply using them.
Setting up an identical local account on both client and server will by definition not involve domain credentials, so that registry key should indeed have no effect in such a configuration.
Can you restore the value of the registry key to 0 (or just wait until it resets at midnight) and repeat your test without using PI AF or any other OSIsoft software?
If it works with non-OSIsoft software, are you in a position to upgrade and test with PI AF Client 2014 (2.6) as well (the server can remain AF Server 2012)?
If it works with Microsoft-only software and still fails with PI AF Client 2014, I suspect that under the hood in the PI AF client we may be calling one of the Windows persistence functions that is supposed to fail when DisableDomainCreds = 0. If so, that means our software has inadvertently introduced an artificial restriction in this particular operating environment.
I will reach out to the PI AF team to see if this configuration is something that has ever been tested. Given all the myriad of Windows registry keys and Group Policies that control authentication, my guess is that it probably has not been tested.
In the short-term, you will likely need to use local accounts or try to push your IT for at least a one-way (external) trust between the L4 / L3 domains. With selective authentication (e.g., technet.microsoft.com/.../cc787623(v=ws.10).aspx) and the 'Allowed to Authenticate' permission (e.g., technet.microsoft.com/.../cc738653(v=ws.10).aspx), Active Directory administrators can put quite granular controls on which domain users/groups can access which domain resources/computers. That is, your AD admins could configure that only a subset of users in the L4 domain can only access the AF Server in the L3 domain. It does not have to be completely wide open with all L4 users accessing all L3 computers. Most people are not aware of this, but Active Directory has had this capability for over a decade. And newer versions of Windows Active Directory continue to add more capabilities to give administrators greater authentication / authorization control and flexibility in the enterprise.
Err, I meant to test with the value of the registry key set back to 1 so that persisting of domain credentials is disabled again.
Thanks for the Idea,
I was able to do it in a Test Client where I had the admin access. It worked :) But in order to do this , I had to change the registry setting
SETTING: 1 – enabled , I had to change it to 0-Disabled
But its unfortunate that on the client machines I am trying to connect, There are Group policies which Disable Saving Domain Credentials, which means I can't save any domain credentials , Even If I force it to save domain credentials the Group Policy automatically reverts the changes I make to the initial value every midnight.