Tuesday, February 12, 2013

Part 1: Under the Covers of OAM11g WNA integration with Multiple AD Forests

This post is part of a larger series on Oracle Access Manager 11g called Oracle Access Manager Academy. An index to the entire series with links to each of the separate posts is available.

This is the first post of a three part series that expands on a great article Matt wrote --- “The (Windows) Natives Are Restless”. Matt’s article covered some configurations, browser settings, and some examples of role mapping, but I want to dive into this whole WNA solution a lot more. So Part 1 will include just what the title eludes to, Under the Covers of the WNA integration with Multiple Active Directory Forests, then Part 2 will cover the details of the WNA configuration to make it work against multiple untrusted or trusted domains, and finally in Part 3) some highlights on leveraging OVD11g to pull it all together and make sure WNA can find the correct user across multiple forests.
As a quick primer if you did not read Matt’s post, WNA stands for Windows Native Authentication. The latest official Oracle document on WNA integration can be found in chapter “43 Configuring Access Manager for Windows Native Authentication”. Basically this is an integration where a client can login to their Windows Desktop, open an Internet browser, then navigate to an OAM11g protected HTTP resource, and go right in using the Kerberos Service Ticket without even being challenged. Neat, but where the mystery lies is how this all flows and magically works behind the scenes. I am a firm believer in visual illustrations to help explain a complicated process, so a good sequence diagram seems like the best way to do it for this topic. Ta da!




Behind the realms and master keytab file store


As I walk through the flow keep in mind that the hostnames and ports could be different in your environment so you will need to just extrapolate and understand I am mapping this flow to HTTP traces and logs from my example environment just for illustration purposes.   I also masked the dates and time in the logs, but the sequence of these events is accurately described based on my personal observations. 

At the first login OAM will load the initial KDC servers listed in the keytab

So before I jump into the sequence steps of the diagram I wanted to point out how OAM will load the data from the master keytab the first time WNA happens.  Below in the Weblogic OAM Managed Access Server log you can see OAM loading all the KDC servers listed in the keytab as it initializes the first Kerberos authentication using WNA.  Notice how it iterates all the KDC servers?  In my case my environment has 5 KDC servers sequenced as FOREST1, FOREST2, etc. to FOREST5.   Also note that my service principal accounts that were created in each KDC Server using KTPASS is iam.melander.us, if each of your service principal accounts are different your log will reflect that.  Another way to see this list is to see my Part 2: How to Configure OAM11g WNA forMultiple AD Forests on how to use klist to list all the service principals and KDC servers in the master keytab.


OAM WEBLOGIC LOG - KERBEROS DEBUG LEVEL
---------------------------------------------------
>>> KeyTabInputStream, readName(): FOREST1.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 75; type: 23
>>> KeyTabInputStream, readName(): FOREST2.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 75; type: 23
>>> KeyTabInputStream, readName(): FOREST3.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 75; type: 23
>>> KeyTabInputStream, readName(): FOREST4.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 75; type: 23
>>> KeyTabInputStream, readName(): FOREST5.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 67; type: 1
>>> KeyTabInputStream, readName(): FOREST5.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 67; type: 3
>>> KeyTabInputStream, readName(): FOREST5.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 75; type: 23
>>> KeyTabInputStream, readName(): FOREST5.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 91; type: 18
>>> KeyTabInputStream, readName(): FOREST5.MELANDER.US
>>> KeyTabInputStream, readName(): HTTP
>>> KeyTabInputStream, readName(): iam.melander.us
>>> KeyTab: load() entry length: 75; type: 17
Added key: 23version: 3
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23.
0: EncryptionKey: keyType=23 kvno=3 keyValue (hex dump)=
0000: 8B 23 18 52 4D 2E 3E 2E   31 88 5A FC 21 02 4C F5  .#.RM.>.1.Z.!.L.



Sequence 1 – 5:  Windows Desktop Login Only

The sequence flows in the above diagram in red are basically everything that happens during the Windows desktop login, and the green sequence flows are part of the OAM authentication process when initially requesting an OAM protected HTTP resource.

Sequence 6:  WebGate Interception and Browser Redirect

As the WebGate intercepts the client’s request for http://portal.melander.us/index.html it tries to determine if the browser has the OAMAuthnCookie_<web serve hostname>.  If not the WebGate will immediately check with the OAM Access Server to determine how it should authenticate.  In this case the OAM Access Server tells the WebGate to send a HTTP 302 and redirects the client to the Access Server authentication host http://iam.melander.us:14100/oam/CredCollectServlet/WNA to do some Windows Native Authentication steps.


HTTP TRACE
---------------------------------------------------
HTTP/1.1 302 Moved Temporarily
Connection: close
Transfer-Encoding: chunked
Location: http://iam.melander.us:14100/oam/CredCollectServlet/WNA?authn_try_count=0&spnegotoken=string&challenge_url=%2Foam%2FCredCollectServlet%2FWNA&request_id=-1010974851419667276&OAM_REQ=&locale=en_US&resource_url=http%253A%252F%252Fportal.melander.us%252Findex.html
Set-Cookie: OAM_REQ=VERSION_4~6jVb8GPbhvhBRSSlg35wrBG6NF8eYu%2bW6aUQefACCr08xA9apcyLJFSYrE2fcxDkgA2IOAholgCM42jgNnuDx15K9n0hxFfOrkAV4nMmEN4syBJL5PUFTU%2blOUznSGoEor1R%2bmFnMkO3ArJz2J%2bwUtJumR9KT3B4KUrNBIBkWSNHwx0lgQBmlItkQZdU4FanW7or1bJ9obj3uyMIzIJaJFbSP9JlNglMcL2KbCktAZzVgvWwLh7o1Nj21JmIa5Be5byF2geGS0VbAh%2fbgNkq3WV0VB7ItxETuxNOo3Z4GDAOZ8jARN47ToPsxpFjLkbxx3u7%2bCdMqJZmXkBmFTjJ1jJP7XBraVaZ9ArrHU%2bypMSjXvg8fXGKJcJFV1EYJKHYzSjVbkI44XIJb15Idhc8%2fQ%2bQMudPRyVRB3DYsQd%2fwW6ej4l8udOSxxXpp7uvz6HhLIRLpBlNsQqf9mFL0QhKneD%2bsnkCexKpZycWmdGhtv3T%2fyQnR1hjMMQcIfk8cq3d0z2f9T2FjItOC2vwfy6cYIHKHKoAx%2bTg3pyD9wii0ySsr7YAIMZDMBYWcBqjlLgUOfhQfq7wKdiwNj7H1YHH3NOoZWUKy2ILo0OwwYc5MR%2fI8ujYUp40PwJiHUXZY5DFl70mLoEh1XA7iVwy1kJrFPmBIoBiHZrEzeWrmrce0%2fvyDxwS51h6GZ83WI45jlEQmFaLF2k1V4yASwGBPG5XmQZYCgtgcCWZATKaSHX6yX8zcfVXBSDEF0KzjI4M%3d; path=/; HttpOnly


Sequence 7:  HTTP 401 Respond with WWW-Authenticate: Negotiate

The OAM Access Server tells the WebGate to respond with a HTTP 401 and an additional header WWW-Authenticate: Negotiate say we need to use Kerberos to negotiate authentication. 

HTTP TRACE
---------------------------------------------------
HTTP/1.1 401 Unauthorized
Cache-Control: no-cache, no-store
Date: XXX, XX XXX XXXX XX:XX:XX GMT
Pragma: no-cache
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Expires: 0
WWW-Authenticate: Negotiate
WWW-Authenticate: Basic realm="OAM 11g"


Sequence 8:  Browser sends the Kerberos Token over HTTP

Next the browser will send the Kerberos token to the OAM Access Server for processing.

HTTP TRACE
---------------------------------------------------
GET /oam/CredCollectServlet/WNA?authn_try_count=0&spnegotoken=string&challenge_url=%2Foam%2FCredCollectServlet%2FWNA&request_id=684028674492683329&OAM_REQ=&locale=en_US&resource_url=http%253A%252F%252Fportal.melander.us%252Findex.html HTTP/1.1
Host: iam.melander.us:14100
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:20.0) Gecko/20100101 Firefox/20.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Cookie: OAM_REQ=VERSION_4~SpniCadlpD2uzvOHLApdZY9RgF2ZalJxlxgk58fvhFDY4i4ZMQFiBajsEYVypYr96d8bQwwKMw3NREi3c2xCzK7WEihLoUbs2AA1rk40XwXmS3ODfusGamPR2%2brYp7hNxqDQUaEtSelv1JOmEqKp0eHbRyEKkPTQ6nfxzupykWujqV55tMnwtcG7ZDu%2bvo22DwZNaFUt9OlBhYarndqU0bTi87retmEKay1bUe08UlOKrEdUuc8%2b%2fMRwSZF0SVD9c5WlsKhOyfZfEjBm34U32NIUlabpacRDJiqDTOb8m8VmdYF%2f86sTJXCHK3UvpJ8AM8HOk%2b9fOZRZvR8G%2bXzOYnN8LHJKUS06KLyC9RMjVgIRAtvC0UzFW1HrvNw0%2fkPOFNrVk1Gj%2f0Nc8uQG3jb5Wf%2fyNbFhCGf3F3wgECcp2X8DxBBLUHxlmJg%3d<removed extra length for illustration>
Connection: keep-alive
Authorization: Negotiate YIIFGwYGKwYBBQUCoIIFDzCCBQugJDAiBgkqhkiC9xIBAgIGCSqGSIb3EgECAgYKK
wYBBAGCNwICCqKCBOEEggTdYIIE2QYJKoZIhvcSAQICAQBuggTIMIIExKADAgEFo
a4W0NtIxsPHagvL8BX3+9PtsTHVNH2Yr2pjl1UH/757/st+<removed extra length for illustration>

Sequence 9:  Get Kerberos Token from Browser

OAM Access Server accepts the Token to use SPNEGO, more on this here http://en.wikipedia.org/wiki/SPNEGO.  Then OAM prepares to check the Keytab and validate what KDC this Token came from (Notice in the OAM log below the SPNEGO NegTokenTarg).

OAM WEBLOGIC OAM_SERVER LOG - KERBEROS DEBUG LEVEL
---------------------------------------------------
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 1701245029
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Krb5Context setting mySeqNumber to: 643706622
SPNEGO Negotiated Mechanism = 1.2.840.113554.1.2.2 Kerberos V5
SpNegoContext.acceptSecContext: mechanism wanted = 1.2.840.113554.1.2.2
SpNegoContext.acceptSecContext: negotiated result = ACCEPT_COMPLETE
SpNegoContext.acceptSecContext: sending token of type = SPNEGO NegTokenTarg
SpNegoToken NegTokenTarg: sending additional token for MS Interop
SpNegoContext.acceptSecContext: sending token = a1 81 eb 30 81 e8 a0 03 0a 01 00 a1 0b 06 09 2a 86 48 86 f7 12 01 02 02 a2 69 04 67 60 65 06 09 2a 86 48 86 f7 12 01 02
KeyTab instance already exists
Added key: 23version: 3
Ordering keys wrt default_tkt_enctypes list
default etypes for default_tkt_enctypes: 23. 
0: EncryptionKey: keyType=23 kvno=3 keyValue (hex dump)=
0000: 8B 23 18 52 4D 2E 3E 2E   31 88 5A FC 21 02 4C F5  .#.RM.>.1.Z.!.L.

Sequence 10 - 11:  Find the correct KDC server by checking the Realm in the krb5.conf

Looking at the Access Server log below you see it searching for the KDC server in the krb5.conf file using the master keytab.  Using the Token it will test each keytab until it finds one that validates and once it does it should give a status KrbApReq: authenticate success.  The Access Server during this process contacts the KDC server, so it is very important that the Access Server can resolve the KDC server hostname and also reach it via UDP over TCP on port 88.   If the Access Server cannot contact the KDC or if the UDP port is blocked, authentication will immediately fail and oddly OAM returns a message “The user account is locked or disabled.  Please contact the System Administrator.”, which is misleading though the point is the authentication will immediately fail.   You should also know this process is done in real time, so for example if there are any network or DNS issues that prevents OAM from contacting the KDC at the time of any WNA authentication, it will immediately fail and the message I mentioned will be presented.  Once the KDC network or DNS issue is resolved the authentication will again work without any service restarts or changes to OAM.

OAM WEBLOGIC OAM_SERVER LOG - KERBEROS DEBUG LEVEL
---------------------------------------------------
default etypes for default_tkt_enctypes: 23. 
>>> KrbAsReq calling createMessage
>>> KrbAsReq in createMessage
>>> KrbKdcReq send: kdc=forest1.melander.us UDP:88, timeout=30000, number of retries =3, #bytes=166
>>> KDCCommunication: kdc=forest1.melander.us UDP:88, timeout=30000,Attempt =1, #bytes=166
>>> KrbKdcReq send: #bytes read=164
>>> KrbKdcReq send: #bytes read=164
>>> KdcAccessibility: remove forest1.melander.us
>>> KDCRep: init() encoding tag is 126 req type is 11
>>>KRBError:
         sTime is XXX XXX XX XX:XX:XX CDT XXXX 1401812121000
         suSec is 300663
         error code is 25
         error Message is Additional pre-authentication required
         realm is FOREST1.MELANDER.US
         sname is krbtgt/FOREST1.MELANDER.US
         eData provided.
         msgType is 30
>>>Pre-Authentication Data:
         PA-DATA type = 11
         PA-ETYPE-INFO etype = 23
         PA-ETYPE-INFO salt = 
AcquireTGT: PREAUTH FAILED/REQUIRED, re-send AS-REQ
>>>KrbAsReq salt is FOREST1.MELANDER.USHTTPiam.melander.us
default etypes for default_tkt_enctypes: 23. 
Pre-Authenticaton: find key for etype = 23
AS-REQ: Add PA_ENC_TIMESTAMP now 
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> KrbAsReq calling createMessage
>>> KrbAsReq in createMessage
>>> KrbKdcReq send: kdc=forest1.melander.us UDP:88, timeout=30000, number of retries =3, #bytes=249
>>> KDCCommunication: kdc=forest1.melander.us UDP:88, timeout=30000,Attempt =1, #bytes=249
>>> KrbKdcReq send: #bytes read=1318
>>> KrbKdcReq send: #bytes read=1318
>>> KdcAccessibility: remove forest1.melander.us
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
>>> KrbAsRep cons in KrbAsReq.getReply HTTP/iam.melander.us
Found key for HTTP/iam.melander.us@FOREST1.MELANDER.US(23)
Entered SpNegoContext.acceptSecContext with state=STATE_NEW
SpNegoContext.acceptSecContext: receiving token = a0 82 05 0f 30 82 05 0b a0 24 30 22 06 09 2a 86 48 82 f7 12 01 02 02 06 09 2a 86 48 86 f7 12 01 02 02 06 0a 2b 06 01 
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.48018.1.2.2
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.2.840.113554.1.2.2
SpNegoToken NegTokenInit: reading Mechanism Oid = 1.3.6.1.4.1.311.2.2.10
SpNegoToken NegTokenInit: reading Mech Token
SpNegoToken NegTokenInit : no MIC token included
SpNegoContext.acceptSecContext: received token of type = SPNEGO NegTokenInit
SpNegoContext: negotiated mechanism = 1.2.840.113554.1.2.2
Entered Krb5Context.acceptSecContext with state=STATE_NEW
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Using builtin default etypes for permitted_enctypes
default etypes for permitted_enctypes: 3 1 23 16 17. 
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
object 0: 1401812121000/297
object 0: 1401812121000/297
replay cache found.
>>> KrbApReq: authenticate succeed.
Krb5Context setting peerSeqNumber to: 85335024
>>> EType: sun.security.krb5.internal.crypto.ArcFourHmacEType
Krb5Context setting mySeqNumber to: 703946614
SPNEGO Negotiated Mechanism = 1.2.840.113554.1.2.2 Kerberos V5
SpNegoContext.acceptSecContext: mechanism wanted = 1.2.840.113554.1.2.2
SpNegoContext.acceptSecContext: negotiated result = ACCEPT_COMPLETE
SpNegoContext.acceptSecContext: sending token of type = SPNEGO NegTokenTarg
SpNegoToken NegTokenTarg: sending additional token for MS Interop
SpNegoContext.acceptSecContext: sending token = a1 81 eb 30 81 e8 a0 03 0a 01 00 a1 0b……(Full token has been removed)


In Part 2:How to Configure OAM11g WNA for Multiple AD Forests I will cover how to setup the krb5.conf and create the master.krb5.keytab files.  I should also point out that one reason this solution works is that all the KDC server keytabs are in a single master.krb5.keytab file.  This will also work with KDC servers that have a Transitive trust between them, either way this will work in all cases.

TIP:  If you see any Kerberos logs that show a KRBError, this is benign and does not impact anything to do with the authentication.  Below is an example of this error.

        >>>KRBError:
         sTime is Thu Feb 07 17:11:51 CST 2013 1360278711000
         suSec is 568642
         error code is 25
         error Message is Additional pre-authentication required
         realm is FOREST2.EXAMPLE.COM
         sname is krbtgt/FOREST2.EXAMPLE.COM
         eData provided.
         msgType is 30

To see Kerberos logs in the OAM Server logs, it has to be turned on by inserting a couple lines in the setDomainEnv.sh file; more on this in part 2 of this series.

To see Kerberos logs in the OAM Server logs, it has to be turned on by inserting a couple lines in the setDomainEnv.sh file; more on this in part 2 of this series.

Sequence 12:  Searching for the Authenticated User in the Identity Store

Now that OAM has validated the Kerberos ticket there are a few things that are happening.   The OAM Kerberos module extracts the Principal from the Kerberos ticket; we can see this in the following example log below.  Notice the parameter “Principal:”, it contains the fully qualified user Principal Name tim.melander@FOREST1.EXAMPLE.COM.

OAM_SERVER DIAGNOSTIC LOG – TRACE:16 LEVEL DEBUG
---------------------------------------------------
[XXXX-XX-XXTXX:XX:XX.646-06:00] [oam_server1] [TRACE:16] [] [oracle.oam.plugin] [tid: [ACTIVE].ExecuteThread: ’0′ for queue: ‘weblogic.kernel.Default (self-tuning)’] [userId: <anonymous>] [ecid: 4aaf7073ad441920:2e5d74e2:13cb78ddb56:-8000-0000000000000040,0] [SRC_CLASS: oracle.security.am.common.diagnostic.DiagnosticUtil] [APP: oam_server] [SRC_METHOD: init] Grabbed Phase event:oracle.security.am.plugin.diagnostic.PluginPhaseEvent@39cb37ff
4941,1 40%
Principal: tim.melander@FOREST1.EXAMPLE.COM


Next the OAM Kerberos module strips the @FOREST1.MELANDER.US off, which leaves just “tim.melander”; see the parameter Kerb User Name in the example OAM trace log below.  This will then be used to search for the user’s samAccountName in Active Directory via the identity store defined in the authentication module.  The identity store in this case is defined to use OVD, and the DIT has been designed to look like each respective Active Directory namespace; more on this in part 3 and how to best define the DIT in OVD to work with this solution.  I also want to point out that the Identity Store does not have to be configured directly to Active Directory; it could be configured to use any Directory Server that has been certified with OAM.  Active Directory is only used to accomplish the Kerberos authentication, again more on this in Part 3:OAM11g WNA Identity Store Considerations and Configurations.

OAM_SERVER DIAGNOSTIC LOG – TRACE:16 LEVEL DEBUG
---------------------------------------------------
[XXXX-XX-XXTXX:XX:XX.646-06:00] [oam_server1] [TRACE] [] [oracle.oam.plugin] [tid: [ACTIVE].ExecuteThread: ’0′ for queue: ‘weblogic.kernel.Default (self-tuning)’] [userId: ] [ecid: 4aaf7073ad441920:2e5d74e2:13cb78ddb56:-8000-0000000000000040,0] [SRC_CLASS: oracle.security.am.plugin.authn.KerberosTokenAuthenticator] [APP: oam_server] [SRC_METHOD: process] Kerb User Name  = tim.melander

Next OAM will use the stripped off principal name to search in OVD, but before it does there is a special parameter we set in the custom Kerberos authentication module that is defined in one of the UserIdentificationPlugin’s, it is called KEY_USERDOMAIN, and it is used to dynamically get the proper searchbase.  Shown in the OAM trace log below we can see how the Kerberos module has taken the domain it stripped off earlier, @FOREST1.EXAMPLE.COM, and builds a search base of “dc=forest1,dc=example,dc=com”.   Notice the parameter User Domain, it will hold the namespace OAM will use to build its search against OVD.

OAM_SERVER DIAGNOSTIC LOG – TRACE:16 LEVEL DEBUG
---------------------------------------------------
[XXXX-XX-XXTXX:XX:XX.646-06:00] [oam_server1] [TRACE] [] [oracle.oam.plugin] [tid: [ACTIVE].ExecuteThread: ’0′ for queue: ‘weblogic.kernel.Default (self-tuning)’] [userId: <anonymous>] [ecid: 4aaf7073ad441920:2e5d74e2:13cb78ddb56:-8000-0000000000000040,0] [SRC_CLASS: oracle.security.am.plugin.authn.KerberosTokenAuthenticator] [APP: oam_server] [SRC_METHOD: process] User Domain = dc=forest1,dc=example,dc=com

Sequence 13:  OVD searches for the User account

OVD uses the LDAP search it gets from OAM to builds its search by setting the searchbase along with the LDAP filter to find the correct tim.melander.  Shown in the OVD diagnostic log we can see from the Base and Filter, it nicely sets all the proper LDAP search parameters.  If we did not use the KEY_USERDOMAIN parameter the search would start at dc=EXAMPLE,dc=COM, and the authentication would of course fail if there were duplicate tim.melander sameAccountNames found across two or more domains.

OVD DIAGNOSTIC LOG – DEFAULT DEBUG
--------------------------------------------------- 
[[XXXX-XX-XXTXX:XX:XX.192-06:00] [octetstring] [NOTIFICATION] [] [com.octetstring.vde.chain.plugins.DumpTransactions.DumpTransactions] [tid: 27] [ecid: 4aaf7073ad441920:-49d5bd7a:13cb14e92f1:-8000-0000000000000232,0:2] !SEARCH Operation: (Transaction#Adapter_Forest4.Dump After.30)[[
BindDN: cn=orcladmin
Base:   dc=FOREST1,dc=EXAMPLE,dc=COM
Scope:  2
Filter: (&(samaccountname=tim.melander)(objectclass=user))
TypesOnly:      FALSE
Attrs:  [mail, cn, description, orclguid, objectclass, displayname, uid, samaccountname]!
]]

Sequence 14:  OVD returns the entry it searched

Next in the OVD diagnostic log we can see how the LDAP entry tim.melander is successfully returned along with any required attributes.  This will validate to OAM that indeed this user also exists in the Identity Store and return any attributes that may be required to set OAM headers needed for critical business decisions.

OVD DIAGNOSTIC LOG – DEFAULT DEBUG
--------------------------------------------------- 
[XXXX-XX-XXTXX:XX:XX.194-06:00] [octetstring] [NOTIFICATION] [] [com.octetstring.vde.chain.plugins.DumpTransactions.DumpTransactions] [tid: 27] [ecid: 4aaf7073ad441920:-49d5bd7a:13cb14e92f1:-8000-0000000000000232,0:2] !SEARCH Entry Before Plugins: (Transaction#Adapter_Forest1.Dump Before.30)[[
DN: CN=Tim Melander,CN=Users,DC=forest1,DC=example,DC=com
displayName: Tim Melander
cn: Tim Melander
sAMAccountName: tim.melander
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: user

Sequence 15 - 16:  OAM sets the OAMAuthnCookie for SSO

Then in flow 15 to 16 OAM after successfully authenticating and finding the user, it sets the proper OAMAuthnCookie for SSO and do a HTTP 302 to redirect the browser to the original requested URL, or if a Success URL were defined in the policy it would redirect the browser to that URL.

HTTP TRACE
---------------------------------------------------
HTTP/1.1 302 Found
Date: Tue, 03 Jun 2014 18:03:33 GMT
Server: Oracle-Application-Server-11g
Set-Cookie: OAMRequestContext_portal.melander.us:80_426645=; Expires=Thursday, 01-Jan-1970 01:00:00 GMT; path=/;
Set-Cookie: OAMAuthnCookie_portal.melander.us:80=6REKqtu%2FlKImJXIqAYegptKkTUYnnjnLh2lrvZANEbwp7dMIpL6EO7sNc3Qxw1VKtpYtHeltJdy3umY6LH7LUdqL9Yl6Eg15fzDlRWP1zE0RPKwjqRdeHt7XIEwga5B8oY6nMw5bFTnlRgiPGRu07gydDa3%2BBs71t5eTbt3wkpTg3g3SWjWv8BCE4R23qDmszoiZlbTLeSswvIAKQYUp8PNR9P8L67hI94enJaG8Bz%2FgLLdJiw3aXZQTxDlLPcnuNvGKizs2ClmIxk6ead36mdUu9YAv3IOsOTClzFtEfreCKBhmSS06ZLAVUboxVfh3zGB5SEg1Vcp0rjBFJbg4S%2F7mR3mPXrbWO6I3Yxq%2F%

Summary


I hope this will help you understand how the entire OAM WNA authentication process works from end-to-end.  Understanding the flow helps considerably in trying to troubleshoot.  As you check out Part 2:How to Configure OAM11g WNA for Multiple AD Forests of this series to understand the detail of how to configure OAM11g for the WNA integration I would suggest referring back to Part 1 to make sure you clearly understand the flow in order to troubleshoot as you run into problems.   Part 2 covers multiple domains whether they are trusted or untrusted, and I will also include tips on troubleshooting.


No comments:

Post a Comment

Note: Only a member of this blog may post a comment.

Post a Comment