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.
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.
Posts
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.