Forum Discussion
NimbostratusSSO/ KERBEROS DELEGATION
Hello Guys, I'm trying to set up a kerberos delegation to an existing SharePoint web application so that it works transparently after a user has authenticated to our domain (SSO). This application, at the SharePoint and IIS levels, already supports kerberos. There is already an SPN created for the application's application pool identity (spmyapp). According to the F5 documentation, I need to create a .keytab file with the ktpass command and an SPN. But there is already an SPN for spmyapp.
Questions:
(1) Can I skip the setspn step, because there is already an SPN?
(2) Do I need to create the .keytab file using ktpass and the existing app pool identity (spmyapp)? If 'yes', is this the correct command?:
ktpass -princ HTTP/appname.example.com@EXAMPLE.COM -mapuser spmyapp@EXAMPLE.COM -crypto rc4-hmac-nt -ptype KRB5_NT_PRINCIPAL -pass -out c:\spmyapp.keytab
(3) If I am supposed to run ktpass using a different account (not spmyapp), then how do I make sure I don't create a duplicate SPN for the same service?
(4) Is this the right process (SPN + .keytab file) or have I missed something here?
1 Reply
- Kevin_Stewart
Employee
You're actually talking about two different things here, which is a common misconception. APM performs Kerberos in a proxy environment, in which case client side Kerberos (client to APM) is COMPLETELY separate and distinct from server side Kerberos (APM to server). Client side Kerberos is generally referred to as a AAA function, and entails the creation of a keytab; while server side Kerberos is generally referred to as an SSO function, and does not require the creation of a keytab. As with any AAA function, successful client side Kerberos authentication produces a set of session values that can be used with other authentication and authorization functions. And as with any SSO function, Kerberos server side authentication requires a set of inputs (specifically a user name and a domain name). Where you get the inputs to server side Kerberos is somewhat arbitrary. So in order to use client side and server side Kerberos together, you'd use the output from the AAA (a username and domain) as input to the server side Kerberos. But more important, also understand that SPNs will also be different. The SPN created in the keytab for AAA will be the SPN the client will use to request a ticket (the VIP FQDN). The SPNs used on the server side will be the SPNs of the individual servers (which the client wouldn't know about).
