Learn F5 Technologies, Get Answers & Share Community Solutions Join DevCentral

Filter by:
  • Solution
  • Technology
Clear all filters
Answers

Multiple apps doing kerberos

Hi all...I am setting up a new BIG-IP environment (v.11.5.1) to front multiple backend services. What is the simplest way to have multiple services (i.e. webservice1.company.com, webservice2.complany.com, etc) that are completely separate fron one another, utilize kerberos from a single domain? Do I need to create a seperate keytab files for each service? If so, do these each need to utilize a differente service account?

Thanks,

0
Rate this Question

Answers to this Question

placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

1.That transitive (two-way) trust is correctly established

if it is working going directly to server for both domain users wouldn't it confirm two-way transitive trust is established.

Direct isn't the same as delegated. Kerberos delegation adds some complexity.

2.That you're actually talking to the correct target domain KDC

I wonder if BAD MATCH Error is because of request body that I highlighted earlier because it is trying to authenticate delegate user against DOMAIN2.DOMAIN.COM while user doesn't exist. That was the reason we went to two SSO profiles with two different accounts from both domain servers.

You should be using a SPN value for the delegation account.

3.That your delegation account is identified by a userPrincipalName and not a sAMAccountName. I didn't mention this earlier, but it's imperative that the Kerberos SSO delegation account is specified using a UPN format account@domain' versus 'domain\account' or simply 'account'.

It's not required in a single domain Kerberos SSO, but in a multi-domain, you must specify the delegation account as a servicePrincipalName, and you do so in three places:

  1. In the AD account's User Logon name field
  2. In the AD account's servicePrincipalName field
  3. In the Kerberos SSO account name field

Image Text Image Text Image Text Image Text

This prevents the inevitable ambiguity that occurs when using a single sAMAccountName value.

1
Comments on this Answer
Comment made 19-Dec-2016 by AN 165

Hi Kevin,

Thanks a lot for all your help... That's exactly what I was looking for... I found my SSO configuration has account name = delegate@DOMAIN1.DOMAIN.COM as shows in my previous attachment. I changed to HTTP/delegate.DOMAIN1.DOMAIN.COM and setup spn in AD.. It resolved the issue,, Can't Thanks enough ..

I ended up changing my APM policy variable assignment to following : To achieve sAMAccountName I have following session.sso.token.last.username = expr { [lindex [split [mcget {session.logon.last.username}] \"@\"] 0] } To split domain from session.logon.last.username: session.logon.last.domain = expr { [lindex [split [mcget {session.logon.last.username}] \"@\"] 1] } Tested it's working from both domain. Thanks again for your help ,,,

0
Comment made 09-Jan-2017 by AN 165

Hi Kevin,

I got above config working for my test environment now when I added same config for my non-prod environment... Going to same domain server but different Username and SPN

Account: HTTP/nonprod-delegate.DOMAIN1.DOMAIN.COM

SPN: HTTP/nonprod-url.com

Servers and delegate account still reside on same domain server.. What I found at given time only one URL works... In order for other URL to work I have to wait for TGT to expires.

I have different SSO config for Test and PROD environment.

I am getting following error when I try accessing non-prod URL right after accessing test URL:

f5-ve debug websso.3[7674]: 014d0001:7: Found UCC:user1@DOMAIN1.DOMAIN.COM@DOMAIN1.DOMAIN.COM, lifetime:600 left:525

Not sure why it picking up UCC for different URL... I don't find UCC when I try to access after TGT expires and non-prod url is working.

f5-ve debug websso.3[7674]: 014d0001:7: ctx: 0x9b2e1b8, SERVER: TMEVT_REQUEST f5-ve info websso.3[7674]: 014d0011:6: /frontend/Kerberos-SSO-non-prod:frontend:6593bc9b: Websso Kerberos authentication for user 'user1' using config '/frontend/SSO-non-prod-Kerberos' f5-ve debug websso.3[7674]: 014d0046:7: /frontend/Kerberos-SSO-non-prod:frontend:6593bc9b: adding item to WorkQueue f5-ve debug websso.3[7674]: 014d0021:7: /frontend/Kerberos-SSO-non-prod:frontend:6593bc9b: ctx:0x9b2dce0 SPN = HTTP/nonprod-url.com@DOMAIN1.DOMAIN.COM f5-ve debug websso.3[7674]: 014d0023:7: S4U ======> /frontend/Kerberos-SSO-non-prod:frontend:6593bc9b: ctx: 0x9b2dce0, user: user1@DOMAIN1.DOMAIN.COM, SPN: HTTP/nonprod-url.com@DOMAIN1.DOMAIN.COM f5-ve debug websso.3[7674]: 014d0001:7: Getting UCC:user1@DOMAIN1.DOMAIN.COM@DOMAIN1.DOMAIN.COM, lifetime:600 f5-ve debug websso.3[7674]: 014d0001:7: Found UCC:user1@DOMAIN1.DOMAIN.COM@DOMAIN1.DOMAIN.COM, lifetime:600 left:525 f5-ve debug websso.3[7674]: 014d0001:7: UCCmap.size = 1 f5-ve debug websso.3[7674]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: user1@DOMAIN1.DOMAIN.COM server: HTTP/nonprod-url.com@DOMAIN1.DOMAIN.COM - trying to fetch f5-ve debug websso.3[7674]: 014d0001:7: S4U ======> - NO cached S4U2Self ticket for user: user1@DOMAIN1.DOMAIN.COM - trying to fetch f5-ve err websso.3[7674]: 014d0005:3: Kerberos: can't get S4U2Self ticket for user user1@DOMAIN1.DOMAIN.COM - Matching credential not found (-1765328243) f5-ve err websso.3[7674]: 014d0024:3: /frontend/Kerberos-SSO-non-prod:frontend:6593bc9b: Kerberos: Failed to get ticket for user user1@DOMAIN1.DOMAIN.COM f5-ve err websso.3[7674]: 014d0048:3: /frontend/Kerberos-SSO-non-prod:frontend:6593bc9b: failure occurred when processing the work item f5-ve debug websso.3[7674]: 014d0001:7: ctx: 0x9b2e1b8, SERVER: TMEVT_NOTIFY f5-ve debug websso.3[7674]: 014d0001:7: ctx: 0x9b2e1b8, SERVER: TMEVT_RESPONSE f5-ve debug websso.3[7674]: 014d0001:7: 8 headers received

0
Comment made 02-Feb-2017 by tabernarious 244

If your two Kerberos SSO configurations are for the same REALM this may be a limitation of APM. I ran into this on APM 12.1.1 HF1. This is speculation but I think what happens is that:

Given:

  • Kerberos_SSO_1 (APM Kerberos SSO configuration)

    • REALM_X
    • KDC: dc.domain.com (or blank)
    • Account host/apm_svc_1.domain.com)
  • Kerberos_SSO_2 (APM Kerberos SSO configuration)

    • REALM_X (same as above)
    • KDC: dc.domain.com (or blank)
    • Account host/apm_svc_2.domain.com)

Theory:

  1. If no TGT exists for REALM_X (any previous have expired or been deleted)
  2. Then Kerberos_SSO_1 is activated by an Access Policy and fetches a TGT for REALM_X using domain service account host/apm_svc_1.domain.com and caches it.
  3. Next Kerberos_SSO_2 is activated and sees a cached TGT for REALM_X but getting a Service Ticket may fail because the TGT for REALM_X is already cached from Kerberos_SSO_1 which used domain service account host/apm_svc_1.domain.com which may have different delegation permissions than host/apm_svc_2.domain.com.
  4. Alternatively, if the Kerberos cache is cleared (e.g. using "bigstart restart websso") then Kerberos_SSO_2 could successfully fetch a TGT and Service Ticket, but a subsequent attempt by Kerberos_SSO_1 may fail until the TGT was cleared (or expired).

**This may appear to work if you're using the same domain service account (i.e. you have two identical Kerberos SSO configs), but I can't say that for sure. And in this case you're not actually trying to do something different so there may be no conflict.

**I've also seen attempts to have different Kerberos SSO configurations for the same realm but pointing to KDCs in different domains and with domain service accounts from different domains (I can't remember why this was attempted). Either way it does not work. For example:

  • Kerberos_SSO_1 (APM Kerberos SSO configuration)

    • REALM_X
    • KDC: dc.domain.com
    • Account host/apm_svc_1.domain.com)
  • Kerberos_SSO_2 (APM Kerberos SSO configuration)

    • REALM_X (same as above)
    • KDC: dc.sub.domain.com
    • Account host/apm_svc_2.sub.domain.com)

If anyone knows the truth I'd be interested to hear it!

**See https://devcentral.f5.com/questions/kerberos-for-different-vs-fails-due-to-cache-50580 for more details. This bug (ID 445501) appears to be fixable and may be soon.

0
Comment made 02-Feb-2017 by Kevin Stewart

Verified. It's bug 445501.

0
Comment made 03-Feb-2017 by AN 165

I am getting following in my logs:

First URL access

~~~~~~~~~~~~~~~~

bigip debug websso.1[27926]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: user1@DOMAIN1.DOMAIN.COM server: HTTP/server1.domain1.domain.com@DOMAIN1.DOMAIN.COM - trying to fetch bigip debug websso.1[27926]: 014d0001:7: S4U ======> - NO cached S4U2Self ticket for user: user1@DOMAIN1.DOMAIN.COM - trying to fetch bigip debug websso.1[27926]: 014d0001:7: S4U ======> - fetched S4U2Self ticket for user: user1@DOMAIN1.DOMAIN.COM bigip debug websso.1[27926]: 014d0001:7: S4U ======> trying to fetch S4U2Proxy ticket for user: user1@DOMAIN1.DOMAIN.COM server: HTTP/server1.domain1.domain.com@DOMAIN1.DOMAIN.COM bigip debug websso.1[27926]: 014d0001:7: S4U ======> fetched S4U2Proxy ticket for user: user1@DOMAIN1.DOMAIN.COM server: HTTP/server1.domain1.domain.com@DOMAIN1.DOMAIN.COM bigip debug websso.1[27926]: 014d0001:7: S4U ======> OK! bigip debug websso.1[27926]: 014d0001:7: GSSAPI: Server: HTTP/server1.domain1.domain.com@DOMAIN1.DOMAIN.COM, User: user1@DOMAIN1.DOMAIN.COM

Second URL access

~~~~~~~~~~~~~~~~~

bigip debug websso.0[27764]: 014d0023:7: S4U ======> /uat-frontend/efd-communitycare-kerberos:uat-frontend:ebce405f: ctx: 0x99fcb58, user: user1@DOMAIN1.DOMAIN.COM, SPN: HTTP/server2.domain1.domain.com@DOMAIN1.DOMAIN.COM bigip debug websso.0[27764]: 014d0001:7: Getting UCC:user1@DOMAIN1.DOMAIN.COM@HEALTH.HIN.SK.CA, lifetime:660 bigip debug websso.0[27764]: 014d0001:7: Found UCC:user1@DOMAIN1.DOMAIN.COM@HEALTH.HIN.SK.CA, lifetime:600 left:363 bigip debug websso.0[27764]: 014d0001:7: UCCmap.size = 2 bigip debug websso.0[27764]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: user1@DOMAIN1.DOMAIN.COM server: HTTP/server2.domain1.domain.com@DOMAIN1.DOMAIN.COM - trying to fetch bigip debug websso.0[27764]: 014d0001:7: S4U ======> - NO cached S4U2Self ticket for user: user1@DOMAIN1.DOMAIN.COM - trying to fetch

It states "Found UCC" not sure what that means..

0
Comment made 23-Feb-2017 by tabernarious 244

@Kevin Stewart: Does BugID 445501 also address multiple Kerberos SSO configurations for the same realm AND the _same delegation account_? (I thought it only broke if you were trying to use different delegation accounts for the same realm). If not, are you familiar with this seemingly similar issue.

On 11.6.0 HF6 I'm running into an issue where we need "Send Authorization" to be "On 401 Status Code" for one application in the realm (SAP using Apache running on Windows). After APM gets and sends the initial Kerberos service ticket to the application, the application returns a MYSAPSSO2 cookie which it uses going forward (no further Kerberos appears to be necessary). For the benefit of others, this application also requires SPNEGO formatted Kerberos tickets and it appears that "On 401 Status Code" uses the SPNEGO format where "Always" uses KRB5 format. You can see the different OID and related data by viewing the Kerberos tickets in Wireshark.

All of the other applications in this realm work with both "Always" and "On 401 Status Code", but all of these other applications require the Kerberos service ticket to be sent for every request. This means there is a lot of extra overhead handling 401 challenges for every request (even though the APM has the Kerberos service ticket for that user cached and can send it immediately).

I am seeing similar type of behavior as described in my post above where:

  • Two Kerberos SSO configurations are set in different Access Profiles:

    1. REALM: X, Account: Y, Send Authorization: Always
    2. REALM: X, Account: Y, Send Authorization: On 401 Status Code
  • These two Access Profiles share session cookies (domain.com) so a user can jump between them without re-authenticating.

  • Starting with no Kerberos tickets cached on APM (timed out or "bigstart restart websso"), if your first Kerberos SSO attempt uses configuration 1 (Send Authorization: Always) it successfully fetches a TGT and Service Ticket and SSO works!
  • If you then make a request that requires Kerberos SSO configuration 2 (Send Authorization: On 401 Status Code) we get this error

Kerberos: can't decrypt S4U2Self ticket for user myusername@DOMAIN.COM - Decrypt integrity check failed

I speculate that APM is trying to use the cached ticket from the other Kerberos configuration but cannot, perhaps due to Kerberos-SSO-configuration-specific encryption (?).

Thanks for any insight you may have.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

JdTokenRing,

Consider that the KDC stores encryption keys in its database based on the name of the services - its "principal name". When a client (or service) requests a ticket from the KDC, it must specify the correct principal name target, so that the KDC can retrieve the correct value. Since APM SSO is the delegate client in this scenario, it doesn't really matter what the DNS name is on the outside, as long as APM knows the real principal name. The APM Kerberos SSO config allows you a few ways to do that:

  • With the SPN Pattern field left blank, SSO uses a reverse DNS lookup of the pool member IP. If DNS returns "siteabbrfunctionnumber.int.ourdomain.com" and "HTTP/siteabbrfunctionnumber.int.ourdomain.com@INT.OURDOMAIN.COM" is the correct SPN for this service, then that should be enough.
  • If the service principal name is the same as the client-requested HTTP Host (which it isn't in your case), you can use the %h option in the SPN Pattern field. Example: "HTTP/%h@INT.OURDOMAIN.COM".
  • If the service principal is something completely different, and unique per server, you can use a local Hosts entry on the F5 and the %s option in the SPN Pattern field. So for example, "HTTP/%s@INT.OURDOMAIN.COM", where %s resolves the pool member IP to an entry in the Hosts file.
  • And if all services use the same principal name (because they use the same service account), you can simply type in a static SPN in the SPN Pattern field. Example, "HTTP/myservice.int.ourdomain.com@INT.OURDOMAIN.COM".

Most important though, the correct service principal name for the service isn't necessarily the name of the box. It depends on the account that owns the application service you're trying to authenticate to. If these are Windows servers, and the application service is owned by the machine account, the the SPN would indeed be based on the name of the box. If the application service is owned by a separate account, then the SPN for the service is that account's SPN.

1
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I think you might need to create 2 virtual servers with 2 different surrogate accounts. And you may have to close the browser(IE) before accessing the second virtual server.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

There are actually a few ways to go about this, but first it's important to distinguish client side and server APM Kerberos as two completely separate things. I mention this because only client side (AAA) APM Kerberos requires a keytab, while server side (SSO) APM Kerberos does not. So with that aside, let's run through some of the options:

  1. Create separate SSO profiles for each - as I'm sure you're aware, Kerberos is dependent on a unique servicePrincipalName (SPN) for each service. This unique SPN maps to an encryption key in the KDC's database, and that encryption key is used to encrypt and decrypt messages to/from the entity that owns that SPN. So for example, let's say you have a Kerberos-enabled web server. That web server service must be associated with a SPN. In IIS that is the SPN assigned to the account that owns a particular application pool (that is then assigned to a website). When a client requests a ticket for a service, it does so by name (SPN). The KDC validates the client's request, generates a ticket, encrypts that ticket with the requested service's key, and then encrypts it all again with the client's key. The client decrypts the outer "shell" and sends the rest to the service. If the client asked for the right service by the right name, the service should have the key necessary to decrypt the inner shell and expose the ticket. If each of your web applications are completely separate in the sense that they cannot share a single Kerberos SPN, then you could create a separate APM Kerberos SSL profile for each and either assign to a respective VIP, or use the WEBSSO::select command in an iRule to switch between the SSO profiles based on some request value (host name, URI pattern, cookie value, etc.).

  2. Create a single SSO profile for all - if, however, the web servers can all share a single service account and corresponding SPN, then you could create a single APM Kerberos SSO profile and use for all of the services.

It's also worth taking a moment to discuss the "SPN Pattern" option in the Kerberos SSO profile. By default, and without this setting defined, the APM Kerberos SSO profile "builds" the SPN dynamically by first performing a reverse DNS lookup of the load balanced IP address, then adding "http/" to the front, and "@REALM_NAME" to the end (the actual uppercase name of the domain realm) to create a SPN (ie. http/server1.domain.com@DOMAIN.COM). It uses this SPN to request a ticket for the downstream service. If, however, that name doesn't match the actual SPN (owner) of the web server, then this process would obviously fail. To get around this, the SPN Pattern field in the profile allows you to specify a static SPN value. Populating this field overrides the reverse DNS process and uses the specified string as the SPN for the ticket request. Now here's where it gets really interesting. That SPN Pattern field can take "wildcard" parameters. The %s wildcard will take the load balanced IP address and query the local Hosts file on the BIG-IP. You can use this option if a DNS lookup isn't going to return the correct SPN host name.

http/%s@DOMAIN.COM

The %h option takes the Host header from the request to generate the SPN (an admittedly less used option). What this means is that you could also, as a third option, create a single Kerberos SSO profile, and either use reverse DNS or the %s wildcard and Hosts entries to dynamically generate the SPN for the ticket request. The AD service delegation account that you create to bind to the APM Kerberos SSO profile can be configured to delegate to all of the web server SPNs.

0
Comments on this Answer
Comment made 28-Jul-2014 by kunjan 3244
if I may add.. If it is about Kerberos SSO case, the current APM limitation forces to use a single SSO profile/delegation account for multiple services in the same realm(ID445501).
0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Yes.... that is a current limitation of APM Kerberos SSO. It basically means that if all of your services are in a single domain realm, you can only have one Kerberos SSO profile and AD delegation account. If the services are in different realms, this shouldn't apply. The alternative is to create a single Kerberos SSO profile, and then use either reverse DNS or SPN patterns and %s wildcards to dynamically generate the SPNs to be used.

0
Comments on this Answer
Comment made 13-Dec-2016 by AN 165

@ Kevin Stewart What is web services reside in Domain1 and we want to authenticate both domain1 and domain2 users using SSO profile. Because SPN will get confusing and we need separate account from domain2 for domains SSO configuration.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Cross-realm limitations don't apply as long as the delegation account (used by APM) is in the same realm as the target service. Cross-realm constrained delegation does, however, require the users to be in a transitively trusted realm.

The only other issue is that APM doesn't support cross-realm referrals. It's something that would happen if a user was in a different realm and the current realm sent a referral to that realm (or at least the next realm closest to this realm). So since APM doesn't understand referrals, you have to tell it which realm the user is in. That may be an LDAP query up front in the access policy, either nested queries or a single GC query. Once you know which the realm the user belongs to, you need to use the user's sAMAccountName in that realm as the SSO username source, and the user's realm realm name as the SSO domain source.

0
Comments on this Answer
Comment made 14-Dec-2016 by AN 165

Image Text We have delegate account (same account used in IIS apppool) from domain1 and web services reside in domain1 as well. We have SPN setup HTTP/xyz.com@DOMAIN1. Both domain1 and domain2 are part of forest maindomain.There is two-trust between them. When I remove APM policy I see kerberos authentication happening at client side and user get into application. But I want F5 to do kerberos AAA authentication and Kerberos SSO. Kerberos AAA works fine for both domains (domain1 and domain2) but Kerberos SSO works only for domain1's user. I have check in place after SSO Credential Mapping and assign SSO configuration accordingly. Please check attached file.

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

In a multi-domain configuration, you MUST use the user's sAMAccountName as the SSO username source, and the user's real domain as the SSO domain name source. APM Kerberos SSO doesn't support referrals, so users in domain1 work because no referrals are needed there. So for example:

session.sso.token.last.username = expr { "bob" }    <--- sAMAccountName
session.logon.last.domain = expr { "DOMAIN1.DOMAIN.COM" }

Are you switching between SSO profiles in the VPE? You don't need to do that if the delegation account and web service are in the same domain.

You also don't need the SSO credential mapping agent in a Kerberos SSO. You just need to populate the above SSO input variables.

0
Comments on this Answer
Comment made 14-Dec-2016 by AN 165

Hi Kevin, That's correct. I am switching to SSO profile based on user domain as SSO profile realm will be different.

Under Variable Assign Domain1 I am achieving same thing by using following: session.sso.token.last.username = expr { [lindex [split [mcget {session.logon.last.username}] \"@\"] 0] } session.logon.last.domain = expr { "DOMAIN1.DOMAIN.COM" }

Also for Variable Assign Domain2 : session.sso.token.last.username = expr { [lindex [split [mcget {session.logon.last.username}] \"@\"] 0] }

session.logon.last.domain = expr { "DOMAIN2.DOMAIN.COM" }

I can see in the logs I am getting user and domain

f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 4, name = From, value = iRule-SSO-Domain2 f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 5, name = To, value = Variable Assign Domain2 f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 6, name = Rule, value = fallback f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 7, name = Agent, value = /frontend/Kerberos-AP_act_variable_assign_1_ag f5-ve debug apmd[4759]: 01490000:7: modules/VariableAssignment/VariableAssignmentAgent.cpp func: "VariableAssignmentAgentexecuteInstance()" line: 1346 Msg: ConfigName: session.sso.token.last.username, ConfigVal user1 f5-ve debug apmd[4759]: 01490000:7: modules/VariableAssignment/VariableAssignmentAgent.cpp func: "VariableAssignmentAgentexecuteInstance()" line: 1346 Msg: ConfigName: session.logon.last.domain, ConfigVal DOMAIN2.DOMAIN.COM f5-ve debug apmd[4759]: 01490000:7: ./AccessPolicyProcessor/SessionState.h func: "clearTempSessionAgentState()" line: 110 Msg: Agent did not initiated the scheduled agent f5-ve debug apmd[4759]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 532 Msg: Let's evaluate rules, total number of rules for this action=1 f5-ve debug apmd[4759]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "execute()" line: 538 Msg: Rule to evaluate = "" f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 8, name = From, value = Variable Assign Domain2 f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 9, name = To, value = Message Box(2) f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 10, name = Rule, value = fallback f5-ve debug apmd[4759]: 01490000:7: queue.cpp func: "setMarker()" line: 377 Msg: queue::setMarker: thread id 1675250544, step 11, name = Agent, value = /frontend/Kerberos-AP_act_message_box_2_ag f5-ve debug apmd[4759]: 01490000:7: AccessPolicyProcessor/AccessPolicy.cpp func: "_executeOneAgent()" line: 134 Msg: user input is required f5-ve debug apmd[4759]: 01490000:7: ApmD.cpp func: "process_apd_request()" line: 1624 Msg: processing of access policy is done, result code=fffffff3 f5-ve debug apmd[4759]: 01490000:7: ApmD.cpp func: "writeSessionVarToSessionDb()" line: 2316 Msg: syncing data with MEMCACHED f5-ve debug apmd[4759]: 01490000:7: memcache.c func: "mc_convert_session_var_to_mc_key()" line: 2564 Msg: Converted Var: session.logon.last.domain to Session Var tmm.session.ce25bdcb.session.logon.last.domain f5-ve debug apmd[4759]: 01490000:7: memcache.c func: "mc_convert_session_var_to_mc_key()" line: 2564 Msg: Converted Var: session.sso.token.last.username to Session Var tmm.session.ce25bdcb.session.sso.token.last.username f5-ve info apmd[4759]: 01490006:6: /frontend/Kerberos-AP:frontend:ce25bdcb: Following rule 'fallback' from item 'Variable Assign Domain2' to item 'Message Box(2)' f5-ve info apmd[4759]: 01490004:6: /frontend/Kerberos-AP:frontend:ce25bdcb: Executed agent '/frontend/Kerberos-AP_act_message_box_2_ag', return value 3 f5-ve info apmd[4759]: 01490007:6: /frontend/Kerberos-AP:frontend:ce25bdcb: Session variable 'session.logon.last.domain' set to 'DOMAIN2.DOMAIN.COM' f5-ve info apmd[4759]: 01490007:6: /frontend/Kerberos-AP:frontend:ce25bdcb: Session variable 'session.sso.token.last.username' set to 'user'

0
Comment made 15-Dec-2016 by AN 165

So Kevin I tried variable assignment for DOMAIN2 User as you suggested and have one SSO profile (DOMAIN1-where all services and delegate account resides) assigned to APM policy:

session.sso.token.last.username = expr { "user" }
session.logon.last.domain = expr { "DOMAIN2.DOMAIN.COM" }

And got following error in the logs.

Dec 15 09:02:21 f5-ve debug websso.1[11095]: 014d0001:7: S4U ======> - NO cached S4U2Proxy ticket for user: user@DOMAIN2.DOMAIN.COM server: HTTP/xyz.com@DOMAIN1.DOMAIN.COM - trying to fetch Dec 15 09:02:21 f5-ve debug websso.1[11095]: 014d0001:7: S4U ======> - NO cached S4U2Self ticket for user: user@DOMAIN2.DOMAIN.COM - trying to fetch Dec 15 09:02:21 f5-ve err websso.1[11095]: 014d0005:3: Kerberos: can't get S4U2Self ticket for user user@DOMAIN2.DOMAIN.COM - Ticket/authenticator don't match (-1765328348) Dec 15 09:02:21 f5-ve err websso.1[11095]: 014d0024:3: /frontend/Kerberos-Test:frontend:26c1742f: Kerberos: Failed to get ticket for user user@DOMAIN2.DOMAIN.COM Dec 15 09:02:21 f5-ve err websso.1[11095]: 014d0048:3: /frontend/Kerberos-Test:frontend:26c1742f: failure occurred when processing the work item

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Okay, just to be clear, the delegation account (used by APM) and the web service MUST be in the same domain. You don't need, and should not use multiple SSO profiles. You just need the one SSO profile.

If it still fails after removing the second SSO profile, take a tcpdump from the BIG-IP

 tcpdump -lnni [vlan between APM and KDC] -Xs0 -w [write to file.pcap]     

Or run a wireshark capture from the KDC directly and observe the Kerberos traffic. The error you see there will be more descriptive than the APM log.

0
Comments on this Answer
Comment made 15-Dec-2016 by AN 165

I did captured and found AS-REQ goes to DOMAIN1 controller and Response sent from DOMAIN1 controller with ticket. TGS-REQ goes to DOMAIN1.DOMAIN.COM controller and get TGS-REP from DOMAIN1 controller. Second TGS-REQ goes to DOMAIN.COM Controller and get TGS-REP from DOMAIN.COM controller Third TGS-REQ goes to DOMAIN2.DOMAIN.COM controller and GET KRB Error: KRB5KRB_AP_ERR_BADMATCH Please check the attached files Overall Kerberos Communication: Image Text

Kerberos Request to DOMAIN2.DOMAIN.COM Image Text

Kerberos Response from DOMAIN2.DOMAIN.COM Image Text

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

I don't have my Kerberos testing lab up and running, so can't say specifically if that is an issue. The bad match error does indicate that the target KDC doesn't like something in the ticket though. I'd check the following things:

  1. That transitive (two-way) trust is correctly established
  2. That you're actually talking to the correct target domain KDC
  3. That your delegation account is identified by a userPrincipalName and not a sAMAccountName. I didn't mention this earlier, but it's imperative that the Kerberos SSO delegation account is specified using a UPN format account@domain' versus 'domain\account' or simply 'account'.
0
Comments on this Answer
Comment made 16-Dec-2016 by AN 165

Hi Kevin, I really appreciate for your expert knowledge. I am trying to understand SSO configuration on F5.

  1. That transitive (two-way) trust is correctly established

if it is working going directly to server for both domain users wouldn't it confirm two-way transitive trust is established.

2.That you're actually talking to the correct target domain KDC

I wonder if BAD MATCH Error is because of request body that I highlighted earlier because it is trying to authenticate delegate user against DOMAIN2.DOMAIN.COM while user doesn't exist. That was the reason we went to two SSO profiles with two different accounts from both domain servers.

3.That your delegation account is identified by a userPrincipalName and not a sAMAccountName. I didn't mention this earlier, but it's imperative that the Kerberos SSO delegation account is specified using a UPN format account@domain' versus 'domain\account' or simply 'account'.

I have following SSO Profile Image Text

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

We have a similar setup (users need to be authenticated to multiple back end applications), we are trying to do KCD but here is my confusion. We use lots of "easy to remember" aliases for sites not their computer names for users to access. For example - time recording site is "timekeeping.ourdomain.com" instead of the server name which is siteabbrfunctionnumber .int.ourdomain.com. So when reading about this in provisioning the service account and adding spns, I did select their computer names from AD and added to the account. However upon further reading, it would seem I need to set the spn's for the aliases as well, but cant do that through the gui so need to add them command line? Before I do that, this is the error I am getting:

Dec 14 17:50:53 nmnbig02 err websso.5[14574]: 014d0024:3: /Common/int-wso-idp:Common:a2baa8d5: Kerberos: Failed to get ticket for user <username>@INT.OURDOMAIN.COM

Dec 14 17:50:53 nmnbig02 err websso.5[14574]: 014d0048:3: /Common/int-wso-idp:Common:a2baa8d5: failure occurred when processing the work item

So if it couldnt get a ticket its because there wasnt a match for the spn right? Please forgive my ignorance I am new to Kerb. Also is there a good primer for Kerb that you would recommend?

Thanks in Advance

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

Kevin,

Thanks so much! That explains alot! All of these services are running as the "App pool" I believe not a particular service account. However if we did this same practice to say Sharepoint which uses host names for site rendering and its running under a service account, is that where I would need to configure that account for delegation and add a SPN for it in particular? Is there a good Kerb reference you would recommend? I have a feeling this could get really complicated, and I do not want to unknowingly do something that would end up passing out "golden tickets" LOL! Many thanks for your help so far!!

John

0
placeholder+image
USER ACCEPTED ANSWER & F5 ACCEPTED ANSWER

JdTokenRing,

However if we did this same practice to say Sharepoint which uses host names for site rendering and its running under a service account, is that where I would need to configure that account for delegation and add a SPN for it in particular?

Yes. You just have to make sure that APM is requesting a ticket for the correct service principal name.

Is there a good Kerb reference you would recommend?

The Kerberos RFCs (1510 and 4120) are a great (albeit dry) place to start, plus there a few books on Amazon that give it decent coverage.

0