Service ticket not found in the subject>>> Credentials acquireServiceCreds: same realmUsing builtin default etypes for default_tgs_enctypesdefault etypes for default_tgs_enctypes: 18 17 16 23.>>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType>>> KdcAccessibility: resetgetKDCFromDNS using UDP>>> KrbKdcReq send: kdc=host1.corp.mycompany.com. TCP:88, timeout=30000, number of retries =3, #bytes=1884>>> KDCCommunication: kdc=host1.corp.mycompany.com. TCP:88, timeout=30000,Attempt =1, #bytes=1884>>>DEBUG: TCPClient reading 4222 bytes>>> KrbKdcReq send: #bytes read=4222>>> KdcAccessibility: remove host1.corp.mycompany.com.:88>>> EType: sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType>>> KrbApReq: APOptions are 00000000 00000000 00000000 00000000>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacETypeKrb5Context setting mySeqNumber to: 593649774Krb5Context setting peerSeqNumber to: 0Created InitSecContextToken:...
U00045013 The SPN 'UC4_EXP/uc4-a.mycompany.com' will be used by this JWP.
C:\>setspn -L UC41Registered ServicePrincipalNames for CN=UC4 ,OU=SPC,OU=SpecialUser,DC=corp,DC=mycompany,DC=com:UC4_EXP/uc4-a.mycompany.comUC4_EXP/uc4-b.mycompany.com
($:/usr/local/ae/server) klist -ek UC4_EXP_FQDN.keytabKeytab name: FILE:UC4_EXP_FQDN.keytabKVNO 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) ...
java -Xmx512M -Dsun.security.krb5.debug=true -jar ucsrvjp.jar ...
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
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).
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 SPNs must be assigned to the previously created KDC service user.
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?
[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.
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.
java ... -Dsun.security.krb5.debug=true -jar
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
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.
AE node host
We opened problem
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
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:
User Interface connects to CP
CP connects to JWP
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
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.
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.
'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?
dns_canonicalize_hostname = truerdns = false
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?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.
Retrieving data ...