Symantec Access Management

My use case might be considered Part 3 with respect to How to setup SiteMinder Kerberos Authentication - Part 1 .  Unlike Part 1 and the proposed Part 2, my customer's environment is comprised of policy servers and login servers hosted on Linux.  Web servers are predominantly on Linux but it's not unusual to find applications deployed on Windows, too.  The user directory is Active Directory.  I believe the customer does not yet have a Key Distribution Center (KDC) in place, so there may be some flexibility to recommend the KDC be hosted on either Linux or Windows.

Does anyone have collateral or experience they could share regarding such a use case? 

This post has also come to my attention.  I'll post further comments after I've had a chance to review it.

https://communities.ca.com/docs/DOC-231172118-kerberosauthenticationwithcasinglesignonreferenceconfigv2pdf

I've been using the collateral from the link referenced in my post 2017-07-06.  While I've made progress, a working configuration eludes me.  The latest hurdle involves not having enough detail in the Web Agent and Policy Server trace logs to be able pinpoint the issue.  Here are sanitized extracts from my log files:

WebAgentTrace.log

[09/14/2017][13:11:05][20714][4104148736][CSmCredentialManager.cpp:260][CSmCredentialManager::GatherAdvancedAuthCredentials][0000000000000000000000008edae590-50ea-59bac639-f4a05700-0b2b1eab9e8c][*192.168.219.107][][hostname-apache-agent][/cgi-bin/dump-headers-kerberos.pl][][SM_WAF_HTTP_PLUGIN->ProcessAdvancedAuthCredentials returned SmSuccess.]

[09/14/2017][13:11:05][20714][4104148736][SmAgentAPI.cpp:2698][Sm_AgentApi_Login][][][][][][][Enter function Sm_AgentApi_Login]

[09/14/2017][13:11:05][20714][4104148736][SmAgentAPI.cpp:2698][Sm_AgentApi_Login][0000000000000000000000008edae590-50ea-59bac639-f4a05700-0b2b1eab9e8c][myusername@ADLAB.DOMAIN.NET" rel="nofollow" target="_blank">http://hostname.adlab.domain.net:8080][][hostname-apache-agent][/cgi-bin/dump-headers-kerberos.pl][myusername@ADLAB.DOMAIN.NETmyusername@ADLAB.DOMAIN.NET][]

[09/14/2017][13:11:06][20700][3625666368][SmAgentAPI.cpp:4879][Sm_AgentApi_DoManagement][][][][][][][Enter function Sm_AgentApi_DoManagement]

[09/14/2017][13:11:06][20700][3625666368][SmAgentAPI.cpp:5099][Sm_AgentApi_DoManagement][][][][][][][Leave function Sm_AgentApi_DoManagement]

[09/14/2017][13:11:07][20714][4104148736][SmAgentAPI.cpp:2927][Sm_AgentApi_Login][][][][][][][Leave function Sm_AgentApi_Login]

[09/14/2017][13:11:07][20714][4104148736][CSmLowLevelAgent.cpp:1343][AuthenticateUser][0000000000000000000000008edae590-50ea-59bac639-f4a05700-0b2b1eab9e8c][*192.168.219.107][][hostname-apache-agent][/cgi-bin/dump-headers-kerberos.pl][][User 'myusername@ADLAB.DOMAIN.NET' is not authenticated by Policy Server.]

smtracedefault.log

[09/14/2017][14:11:07][3889421168][][][][][][][][][][][][][][Failed to validate user myusername@ADLAB.DOMAIN.NET: Minor Status=-1765328240, Major Status=851968, Message=Wrong principal in request][][][][][][][][32045][SmAuthenticate][][][14:11:07.275][][][][][][][][][][][][][][][][][][][][][][][][][][][][][smauthkerberos.cpp:442]

I've done my best to maximize the level of logging in both files.  The web agent trace does not identify the principal in the ticket sent to the policy server, and the policy server does not indicate what principal it received from the web agent or what principal it expects to see. I have also obtained a Wireshark trace between the web agent and the policy server, but all traffic between those two components regarding Kerberos tickets is encrypted and cannot be inspected.

Are any techniques available to obtain more detail regarding why the policy servers flags "wrong principal in request"?  

Hi,

Please share with us the principal you put in the ACO for principals, your Authentication Scheme configuration from AdminUI, and run on the Active Directory machines the command :

c:\> setspn -L nameoftheADaccount

for each account that you have created for Policy Server and Web Agent (host and service).

The message "wrong principal in request" means there's a mismatch somewhere. Note that those principal are case sensitive.

Make sure also that those accounts have the same kvno in the keytab and in the RDC (Active Directory).

Best Regards,

Patrick

Those are relevant questions, but for now I would like to stay focused on the specific question I posed.  The policy server is reporting an error of "wrong principal in request", so it's clear the code is expecting one principal and getting another.  Is there a tool, technique, or logging configuration to cause the policy server to list the expected and submitted principals?  Having this information available in the trace logs would be of general use in pinpointing the specific configuration element that is not correct.  Wireshark can't be used to inspect traffic between the web agent and the policy server because those packets are encrypted, so we're dependent on the trace logs to provide this detail.

I will propose an enhancement request if the trace logs are not currently capable of being cajoled into providing the details regarding why the "wrong" principal is in the request. 

Hi Fauri02,

You mentionned :

 Is there a tool, technique, or logging configuration to cause the policy server to list the expected and submitted principals? 

That's why I requested you those details. Outside this, I don't know other ways to get those info.

Best Regards,

Patrick

It turns out that the SiteMinder web agent, policy server, AD and Kerberos configurations were all correct.  It's not intuitive, but the 'wrong principal in request' error will also occur if using Firefox and this variable is not set in about:config:

network.negotiate-auth.delegation-uris = .some.domain.com

I had already defined network.negotiate-auth.trusted-uris as the same value shown above, but authentication did not start working until the above parameter was also defined.

At this stage, it's not clear to me that having the policy server log the expected and received principal when the two don't match would have lead me to the conclusion that Firefox was missing a parameter... but I still think having that detail written to the policy server trace log would be a useful enhancement request.