Has anyone been able to get single sign-on to work in v11.1?
- We have made considerable progress in the past week. I will explain briefly how we resolved the main sticking point — problem 3 (“U00003210 Logon error: Access denied”).
Before, we had created an SPN for every conceivable host name and alias that the server might use to identify itself, because it was not clear which name the server would use. Starting with v11.2 though, the Java Work Process prints a useful message to the JWP log when a user activates integrated authentication in the GUI:U00045013 The SPN 'UC4_EXP/uc4-a.mycompany.com' will be used by this JWP.
Thanks to message U00045013, we can see what SPN the JWP will be using. With the benefit of this knowledge, I realized that the server would actually need only two SPNs. We now have just the SPNs we need:C:\>setspn -L UC41
Our AE server keytab also now contains keys for just these two SPNs:
Registered ServicePrincipalNames for CN=UC4 ,OU=SPC,OU=SpecialUser,DC=corp,DC=mycompany,DC=com:
UC4_EXP/uc4-a.mycompany.com
UC4_EXP/uc4-b.mycompany.com($:/usr/local/ae/server) klist -ek UC4_EXP_FQDN.keytab
Note also that the SPNs have a realm based on the fully-qualified Active Directory domain name CORP.MYCOMPANY.COM. We found that it did not work if we created the SPNs with a realm based on just the short form of the AD domain, CORP.
Keytab name: FILE:UC4_EXP_FQDN.keytab
KVNO Principal
---- --------------------------------------------------------------------------
47 UC4_EXP/uc4-a.mycompany.com@CORP.MYCOMPANY.COM (DES cbc mode with CRC-32)
...
48 UC4_EXP/uc4-b.mycompany.com@CORP.MYCOMPANY.COM (DES cbc mode with RSA-MD5)
...
As soon as we made these changes, single sign-on finally began working, as long as the GUI is started as an admin user. We also found that it was not necessary to change the department of the user object from CORP to CORP.MYCOMPANY.COM. As long as integrated authentication is enabled, it is possible to log in as the a user defined with just CORP in its department, even though the department field is automatically populated with CORP.MYCOMPANY.COM.
If the GUI is started as a non-administrative user, we still see the error “U0003127 Logon error: Access denied” as soon as the integrated authentication check box is enabled (checked) in the login window. We do not have a solution to this yet. When we find a solution to this problem, I will post another update here.
- I'm about to try and attempt to configure this. One thing the documentation says is that the AE server and the workstation the GUI is running from have to be close in date / time. Not quite sure if that means this won't work for us or not. Our AE's will be in one state, but I think they are going to run on UTC time. I currently am in Chicago and that's what my laptop is set to - CST. Am I reading that wrong or is this going to be a problem?
I am definitely following along this thread - great info. Thanks for posting. - Allow me to offer a few pieces of advice:
- Begin your experimentation with single sign-on in an environment in which the Automation Engine server runs onjust one node. I have found that in AE systems running on mulitple nodes, the JWP does not reliably select its SPN based on the hostname of the node where it is running.
- Be sure to use Oracle version of Java, not IBM or some other flavor.
- Don’t forget to install the two JARs ofJava Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policyin
$JAVA_HOME/lib/security. This must be done for both the JRE running the JWP, and the JRE running the UC4 GUI. Thesingle sign-on documentationdid not make this clear before, but it has since been updated. - Similarly, don’t forget to install the proper JDBC driver in AE server
libdirectory. TheJWP installation documentationdescribes this pretty well. - Start the JWP from the command line, with Kerberos debugging enabled. E.g.,
java -Xmx512M -Dsun.security.krb5.debug=true -jar ucsrvjp.jar ...
This will help a lot with troubleshooting problems, because you’ll be able to watch the Kerberos communication between the JWP and the LDAP server.
- Michael Lowry said:
I have found that in AE systems running on mulitple nodes, the JWP does not reliably select its SPN based on the hostname of the node where it is running.
I have discovered that the SPN used by the JWP to identify itself to the KDC is based on the CP to which the User Interface connected. If the Automation Engine runs on more than one node, this can result in the following situation:- User Interface connects to CP on uc4a
- CP on uc4a connects to JWP on uc4b
- JWP authenticates with KDC, using SPN likeUC4/uc4a.mycompany.com@MYREALM
Because it is not possible to predict to which CP the GUI will connect, the keytab on both hosts must contain keys for both SPNs. In other words, it is not possible to use a unique keytab for each node/host, with the keytab containing only the key for that particular host’s SPN.Service Principal Names (SPN) must then be created with the following description:
<AE System Name>/<CP Host Name>[@<Realm>]
<AE System Name>/<Fully qualified Domain Name of the CP Host>[@<Realm>]Automic recommends creating SPNs for each CP host (one SPN with the host name and one with the fully qualified domain name).
The paradigm of having SPNs defined as attributes on users is a peculiarity of the way Microsoft implemented Kerberos support in Active Directory. The Automic documentation clearly indicates that Microsoft-style defintion of SPNs is expected or required:The SPNs must be assigned to the previously created KDC service user.
This suggests that defining the service principals independently of the service user, as would be standard in non-AD environments, may not work.
I am still struggling to get single sign-on working reliably. The current obstacle is that the KDC does not find the SPNs that have been defined on the service user, unless the userPrincipalName is also set to the SPN being used to authenticate. Obviously, this is not a solution because there are four potential SPNs that the JWP could use, but the user can have only one UPN defined.
- I am on 11.2 and I cannot get SSON to work at all even running as admin.
I am not getting the U00045013 message, did you need to turn something on to get this?
I am currently running on 1 server with all my CPs, WPs, and JWP on that, I see it loading the KeyTab, but always “U00003210 Logon error: Access denied”.
I'm not sure where else to look, any suggestions?
Yeah, Start the JWP from the command line, with Kerberos debugging enabled. E.g.,Brandon McClure said:I am on 11.2 and I cannot get SSON to work at all even running as admin.
I am not getting the U00045013 message, did you need to turn something on to get this?
I am currently running on 1 server with all my CPs, WPs, and JWP on that, I see it loading the KeyTab, but always “U00003210 Logon error: Access denied”.
I'm not sure where else to look, any suggestions?java -Xmx512M -Dsun.security.krb5.debug=true -jar ucsrvjp.jar ...
Monitor the standard output and JWP log while you try to log in, and note when the error appears. I.e., does it appear when you enable the Integrated authentication check box, or when you click OK to log in?
- So I'm getting closer, Still getting Access Denied, but I can see it using my SPN and pulling all the correct info. Now when I
try to login my UCDJ_LOG shows:
U04002598 Error = ' in com.uc4.C.I [AWT-EventQueue-0] : An exception has occurred in UCCommand.login(UCAncientComponent): Kerberos Autentication java.security.PrivilegedActionException: GSSException: No valid credentials provided (Mechanism level: Server not found in Kerberos database (7))'
My WPsrv_log shows:U00045014 Exception 'javax.security.auth.login.LoginException: "KrbException: Cannot locate default realm"' at 'com.sun.security.auth.module.Krb5LoginModule.attemptAuthentication():653'.U00045015 The previous error was caused by 'sun.security.krb5.RealmException: "KrbException: Cannot locate default realm"' at 'sun.security.krb5.Realm.getDefault():68'.U00045015 The previous error was caused by 'sun.security.krb5.KrbException: "Cannot locate default realm"' at 'sun.security.krb5.Config.getDefaultRealm():1029'. - I think that error should be easy to fix. Google it. I’m sure there are answers on Stack Overflow.
- Michael Lowry wrote:I just spoke with an Automic developer about this issue, and confirmed something I had long suspected:
[T]he KDC does not find the SPNs that have been defined on the service user, unless the userPrincipalName is also set to the SPN being used to authenticate. Obviously, this is not a solution because there are four potential SPNs that the JWP could use, but the user can have only one UPN defined.
A separate service user must be defined for each node on which the Automation Engine runs.
This means that if you run the AE on two nodes, then you must create two separate users. Each service user must be associated with just one AE node. The userPrincipalName attribute of each users must be set to the same thing as the servicePrincipalName. For example:AE node host name Service user UPN SPN uc4a.mycompany.com uc4a UC4/uc4a.mycompany.com@MYREALM UC4/uc4a.mycompany.com@MYREALM uc4b.mycompany.com uc4b UC4/uc4b.mycompany.com@MYREALM UC4/uc4b.mycompany.com@MYREALM
As I understand it, the process works something like this:- The JWP runs as the service user. So the JWP on uc4a will run as uc4a.
- The JWP selects the SPN it will use to authenticate based on the CP to which the UI connected.
- The JWP contacts the KDC, and checks for the existence of the SPN.
- Whether or not the KDC finds the SPN depends on:
- The user running the JWP, and
- The UPN of this user in the KDC
- 1 person found this helpful
This morning I received an email via a colleague from a AE admin at another company. He was asking for help getting SSO working with the Automation Engine. I wrote up a summary of recommendations and findings based on my experience with this topic. I thought it might be worthwhile to post this summary here.
Single sign-on with the Automation Engine: recommendations & findings
- I found that single sign-on does not work reliably in AE systems running on multiple nodes. I was able to get single sign-on working reliably only when the Automation Engine server was running on just one node. (See the detailed discussion below about SSO on multi-node AE servers.)
- Be sure to use Oracle version of Java, not IBM or some other flavor.
- Don’t forget to install the two
JARs of Java Cryptography Extension (JCE) Unlimited Strength
Jurisdiction Policy in
$JAVA_HOME/lib/security. This must be done for both the JRE running the JWP, and the JRE running the UC4 GUI. The single sign-on documentation did not make this clear before, but it has since been updated. - Similarly, don’t forget to
install the proper JDBC driver in AE server lib directory. The JWP installation documentation describes this pretty
well. One note: LDAP-based connection strings like
jdbc:oracle:thin:@ldap://oraclenameserver…do not work with the JWP. We had to stick with a basic connection string likejdbc:oracle:thin:@oracleserver...
(We opened a product enhancement request for this: PMPER-454: JWP should support LDAP-based Oracle JDBC connection strings in ucsrv.ini) - Initially, to aid
troubleshooting, start the JWP from the command line, with Kerberos
debugging enabled:
java ... -Dsun.security.krb5.debug=true -jar ucsrvjp.jar ...
This will allow you to watch the Kerberos communication between the JWP and the KDC, and pinpoint the underlying causes of many problems. Once you have gotten things working, you cant start the JWP via the service manager. - If you see the error “U0003127 Logon error: Access denied” when turning on the integrated authentication check box in the login window, there are two possible fixes:
- Start the UI as an administrative user; or
- Enable AllowTGTSessionKey in Windows.
SSO on multi-node AE servers
The Automic SSO documentation claims that SSO will work in AE systems running on more than one node. However, I was never able to figure out how to make it work reliably. Firstly, the Automic documentation fails to mention something very important:
1. A separate service user must be defined for each node on which the Automation Engine runs.
A service user (or technical user) must be created to run the JWP. The JWP, running as this user, connects to the KDC to authenticate. The KDC will not be able to find an SPN defined on the service user, unless the userPrincipalName of the currently logged-in user is also set to the SPN being used to authenticate.
Andreas at Automic Development confirmed that it won’t work to use the same service user on both nodes, because the UPN must match the SPN. This means that if you run the AE on two nodes, then you must create two separate users. Each service user must be associated with just one AE node. The userPrincipalName attribute of each user must be set to the same thing as the servicePrincipalName. For example:
AE node host name
Service user
UPN
SPN
uc4a.mycompany.com
uc4a
uc4b.mycompany.com
uc4b
We opened problem ticket PRB00119215 with Automic about this omission from the documentation. They have promised to update the documentation to make it clear that a separate service/technical user must be defined for each AE node.
2. Even with a separate service user defined on each node, SSO may not work reliably in multi-node AE systems
The reason, I believe, is that the JWP does not select the SPN it uses to authenticate with the KDC based on the hostname of the node where the JWP is running, but instead based on the node where the CP to which the UI connected is running.
I’ll explain this in a bit more detail. When the User Interface connects to the AE, it connects to a communications process (CP). Which CP the UI connects to is somewhat unpredictable. (It depends on the order of addresses in the CP list in the uc4config.xml file.)
During single sign-on, the process works like this:
1. User Interface connects to CP
2. CP connects to JWP
3. JWP authenticates with KDC
If all CPs and WPs are running on the same node, it’s simple and will work fine every time.
If however, if the Automation Engine processes are running on multiple nodes, as depicted in the figure to the left, then about half of the time, the CP will connect to a JWP running on a different node. E.g.:
1. User Interface connects to CP on uc4a
2. CP on uc4a connects to JWP on uc4b
3. JWP on uc4b tries to authenticate with KDC using an SPN like UC4/uc4a.mycompany.com@MYREALM
I suspect that because of the above problem, SSO will not work reliably in systems with more than one AE node, even if a unique service user is defined for each AE node.
Automic is investigating this in PRB00111313. I will update this discussion thread soon as I have news from Automic. One possible way of fixing this problem would be to force the CP connect to a JWP running on the same node. (This would mean that at least one JWP would have to be running on any node running a CP.)
The summary above did help me a lot with installing Kerberos for AE 11.2. especially the hint to start the JWP from the command line, with Kerberos debugging enabled was very helpful.
There is one issue left:
Although AllowTGTSessionKeyin Windows is enabled I have to start the UI as an administrative user.Anybody with any ideas?
This discussion starts with the question 'Has anyone been able to getsingle sign-onto work in v11.1?'
Has anyone?
I keep on getting: U00045043 The User Interface did not send a kerberos ticket, therefore a validation is not possible.Our productive AE 11.1 is running on Solaris (SPARC) and the JWP uses SPNUC4/uc4b@MYREALM (without.mycompany.com as it wasn't working with it)
I guess thet the UI did send a Kerberos ticket. But the JWP wasn't happy with it.
- The issue about AllowTGTSessionKey in Windows is solved: This happens when a user is member of the local administrators group (a known Windows issue)
- No, no extra nodes. I guess that my problem has to do something with the missing domain in the SPN. I am investigating further with our AD administrators on Monday.
- I would be interested to know if anyone has been able to get SSO working with a multi-server Automation Engine system.
'U00045043 The User Interface did not send a kerberos ticket, therefore a validation is not possible.' was caused by the fact that the UI didn't find a corresponding SPN (there was no one with the domain in the name; see above).
After defining both SPNs (as recommended in the documentation) I face another problem this time from the JWP: 'Client not found in Kerberos database (6)' caused by 'Identifier doesn't match expected value (906)'.
This means that the JWP doesn't find the corresponding UPN anylonger. But why?- Finally ist was the encryption that causes the error 'Identifier doesn't match expected value (906)'!
As our security policy doesn't allow '-crypto all', AES-256 was the only encryption defined. This was sufficient on Linux. On Solaris Arcfour (RC4) has to be tolerated as well. This might be because on Linux both, the UI and the JWP, use the same SPN with the domain in the name. On Solaris the UI uese the SPN with and the JWP the SPN without the domain in the name. Both SPNs are mapped to the same UPN. - The Automic SSO documentation does not mention anything about the UPN or user principal name, but I have learned that it is very important. Specifically, the UPN associated with the user running the JWP must match one of the SPNs. For this reason, the JWP must run as a different on each AE node.
Also, as I understand it, adding the following options to krb5.conf will eliminate the need to have both short and long SPNs:
With these options, the SPNs and keys need only the long form of the host name (the one with the fully-qualified domain name).dns_canonicalize_hostname = true
rdns = false
- I have updated my PowerShell UCDJ startup script, UC4.ps1, to write Kerberos debugging messages to a separate log file. This greatly simplifies troubleshooting single sign-on. If you open an SSO-related ticket with Automic Support, Kerberos debugging output is one of the first things they will ask you to send.
In a conference call with Automic Support & Development today, I learned some important requirements that are not clearly and explicitly stated in the AWA v12 Setting up single sign-on documentation page:
- One service user must be createdfor each node running an Automation Engine communications process, and the CPs on a node must run as the specific service user for that node.
- One service user must be createdfor each node running an Automic Web Interface server. (It does not matter whether the AWI runs as this user.)
- Each service user must haveexactly one service principal name (SPN).
- Each service user must have its user principal name (UPN) set tothe same thing as the SPN.
Example
The Automation Engine system UC4_MAIN runs on two nodes, mars and venus.
The AWI server for this system runs on two nodes, oak and elm.
The company DNS domain name is example.com
The company Kerberos realm name is CORP.EXAMPLE.COM
In this environment, you would create four service users:Node User UPN SPN mars user1 UC4_MAIN/mars.example.com@CORP.EXAMPLE.COMUC4_MAIN/mars.example.comvenus user2 UC4_MAIN/venus.example.com@CORP.EXAMPLE.COMUC4_MAIN/venus.example.comoak user3 HTTP/oak.example.com@CORP.EXAMPLE.COMHTTP/oak.example.comelm user4 HTTP/elm.example.com@CORP.EXAMPLE.COMHTTP/elm.example.com
The Automation Engine (or at least the CPs) must then run as user1 on mars, and as user2 on venus. The keytab must contain four keys: one for each service user.
I am in the process of reconfiguring the service users and keytab to conform to these requirements. I will post an update when I have confirmed that it works correctly.
Update 2016.11.22 18.26 CET: Following these guidelines, I was able to get SSO working in the Java User Interface. I am still trying to figure out how to get SSO working reliably in the AWI.Hi Michael
I have created a PowerPoint that explaines our implementation of Kerberos for the UI and AWI/ECC that might help you with your implementation. I did talk about this matter at the ERFA Meeting in Bendern (Liechtenstein) last month. As the PowerPoint is in German I can't post it here. However, it must be available in your firm.
We don't run the AE (any process) with any of the KDC Service Users. We run the AE the way we always did it before Kerberos. We had to change UC_SYSTEM_SETTINGS, UC_KDC_SETTINGS and UC_USER_LOGON only. Another Change was made for the UI in ucdj.ini: -D[client] instead of -C[client]
- René Stocker wrote:
I can read German. Feel free to post it to the German forum, or to send it directly to me.I have created a PowerPoint that explaines our implementation of Kerberos for the UI and AWI/ECC that might help you with your implementation. I did talk about this matter at the ERFA Meeting in Bendern (Liechtenstein) last month. As the PowerPoint is in German I can't post it here. However, it must be available in your firm.
We don't run the AE (any process) with any of the KDC Service Users. We run the AE the way we always did it before Kerberos. We had to change UC_SYSTEM_SETTINGS, UC_KDC_SETTINGS and UC_USER_LOGON only. Another Change was made for the UI in ucdj.ini: -D[client] instead of -C[client]
As I understand it, in your environment, the service users on which the SPNs are defined are completely different from the users running the Automation Engine. Is this correct? In my experience, this is okay for the service users associated with the AWI, but not for the ones for the Java User Interface. Do you have SSO working in just the AWI, or also the JUI? Hi Michael
You asked:
As I understand it, in your environment, the service users on which the SPNs are defined are completely different from the users running the Automation Engine. Is this correct?
Do you have SSO working in just the AWI, or also the JUI?Yes, service users and users running the AE are completely different. AWI and JUI are both working with SSO.
René Stocker
:
I finally got it working in both the Java UI and the AWI. However, because of security policies, we cannot set AllowTGTSessionKey or allow users to run the Java UI as an Administrator. So SSO via the Java UI is probably not a viable option.
Automic Development confirmed to me late last week that if one plans to provide SSO only via the AWI, then it is not necessary to jump through all the extra hoops of creating service users, SPNs, and keys for the JWP/CP hosts. Instead, just create a single service user, HTTP SPN, and key for the AWI server. I will test this; if it works, then we will likely go this route. It will save us a lot of trouble, and will provide an incentive for users to migrate to the AWI.
- I tested this moments ago, and can confirm that it works. If you want to provide single sign-on capability only via the Automic Web Interface, then…
- Create a single dedicated service user (technical user) for the AWI.
- Create an HTTP SPN for this user, with the host where the AWI will run. The UPN should be set to the same thing as the SPN.
- Create a keytab containing the key for this SPN.
- Place this keytab in the AE server directory on all AE nodes, and set the KEYTAB setting inUC_KDC_SETTINGSto the path to this file.
- Run at least oneJWPon each AE node.
Thank Michael for posting this.. the discussion was helpful in understanding more.. I have followed the SSO documentation along with suggestions from the discussion and did the following.. I m trying to enable SSO only at the AWI level. we have AE Server running on linux and AWI running on windows.
--Installation steps for Automation Engine and AWI
Step 1 = set Windows Regsitry Variable. "allowtgtsessionkey"=dword:00000001
Step 2 = Install JCE. Installed this on all jre/lib/security locations on both AE and AWI Servers/
Step 3 = create krb5.conf, place it in jre/lib/security locations on AWI Server.
Step 4 = in UC_SYSTEM_SETTINGS , set KDC = Y--Installation steps for the JWP
Step1 = Reqeusted Keytab file using below command on the AD Server.
ktpass -princ HTTP/AWI_SERVER_NAME@FQDN -mapuser domain\serverUserId -pass ****** -crypto all -ptype KRB5_NT_PRINCIPAL -out c:\ktfile.keytab
Step2 = create the KEY KEYTAB in UC_KDC_SETTINGS, C:\Automic\SSO\ktfile.keytab
KEYTAB = C:\Automic\SSO\ktfile.keytab
HTTP = HTTP/AWI_SERVER_NAME@FQDNNOTE: JWP was started using following command.
nohup java -Xmx512M -jar /u1/software/automic/server/bin/ucsrvjp.jar &
--Enabling single sign on AWI
Step1 = Add the sso.enabled=true in the C:\Automic\AWI\Tomcat\webapps\awi\config\config.properties file.
The Kerberos enabled option appears but, it keeps loading forever and does not come up with the next option. It currently says "Kerberos login not available".
?= do we have to Place the keytab file on the AWI Server or AE Server? I have placed it on the AWI Server and pointed this location on the AWI GUI.
?= how do we enable kerberos logging? I did not find any logs containing kerberos logs. will this be on the AE Server or AWI server?
Thank you in advance!!
rK
- Create a single dedicated service user (technical user) for the AWI.
- Hi @Michael Lowry,
I've been working to get SSO setup for AWI on our Linux based system. I've gone through the single sign-on setup details and have the krb end of things configured (kinit has verified this) and the AWI login screen showing 'Use Kerberos login' as an opton.
When I opt to use Kerberos login, I get Logon Error: Access Denied and the following in the JWP log:
U00045006 Checking Kerberos token for Single sign-on.
U00045004 Single sign-on is not enabled.
Also in the JWP log, on startup, is the following:
U00045003 Java Cryptography Extension (JCE) Unlimited Strength is not installed.
I have confirmed that JCE is installed in the JRE/lib/security location. I'm guessing there is a coorrelation between this and the system thinking Single sign-on s not enabled.
Did you come across any issues like this when you were looking into SSO? If yes, any suggestions on how to resolve?
I havent yet to get -Dsun.security.krb5.debug=true working, so I cant see the full debug yet. Still working on that.
Thanks,
Eoin
- 1 person found this helpfulPiggy backing on this thread to share some insights I found when getting SSO enabled.
As @Michael Lowry, JCE is important (obviously). What threw me was when I checked my JRE, I could see the policy jars in place. These are not the policy jars required for Unlimited Strength, so when embarking on this, ensure over backup and overwrite the JAR files in your JRE with Oracle JARs referenced in the install documentation.
Probably goes without saying, but you need to have your SSL setup 100% before SSO will work. I only had SSL configured with host alias, not the host name so some confusion arose there.
Make sure you the correct premitted_enctypes in your keytab. I ran into an error stating 'Failure unspecified at GSS-API level (Mechanism level: AES256 CTS mode with HMAC SHA1-96 encryption type not in permitted_enctypes list)'
Looking at my keytab, I found only rc4-hmac was permitted. I needed to add
aes256-cts-hmac-sha1-96 and that was the final hurdle. SSO is now working for me (AWI only)
Next leap is paramaterized logins!
Hi,
I'm having similar troubles..
Setup is two AE-nodes, .. One 'Primary Node', One Standby...
On each node a AWI is implemented..
Keytab, JCE, SPN's as indicated...
SSO works fine when calling the first node... (User+PWD also ok)
Access Denied when using the second node...Both SSO and User+PWD fail. (Department mapping to domain..)
The only thing is... 'Have A JWP Running on both nodes...' -> On the Primary Node this is working as designed.
On the 'Standby Node', the JWP switches to NWP ?
Could that cause SSO to fail on the second node ?
Any thought welcome...
Lieven
1. There appears to be no way to use a department in UC4 that differs from the fully qualified domain used for authentication. We have always used the short form of our AD domain name as the department, and this has never posed a problem until now. The DOMAIN_ALIAS server setting does not appear to work as documented. The only way around this problem that we have found is to change the user object so that the part after the slash (/) — that is, the department — is the fully-qualified domain name.
2. “U0003127 Logon error: Access denied” error when turning on the integrated authentication check box in the login window if the GUI was started as a non-administrative user. The only work-around is to start the GUI as a member of the local Administrators group.
3. “U00003210 Logon error: Access denied” error if the GUI is started as an administrative user, integrated authentication is enabled, and OK is clicked to log in. The GUI fetches a TGT from the AD server, and then prints this to the console:
Then a bunch of hexadecimal data appears in the console, and the error message appears in the GUI.
We would be grateful if anyone could provide work-arounds or suggestions for troubleshooting.