Hi Mohamed,
The video is nowhere to be found, apologies for that.
Indeed, I don't recall exactly what it is that I was wanting to point at by removing the
HTTP@test.domain-2.com Kerberos Service Name. I believe it was to show the scenario where, if both h
ttp://wga-wrp1.domain-1.com and
http://test.domain-2.com would be pointing to the same IP address, a DNS reverse name resolution would show conflicting names, with the potential of SPNEGO authentication not working correctly. (with the error message DPWWA2409W in the Reverse Proxy message log).
The 2 KTPASS commands,
Ktpass -princ HTTP/test.domain-2.com@DOMAIN-1.COM -mapuser wrp-test -mapOp set -crypto All -out c:\test.domain-2.com.keytab -pass Madrid00 -type KRB5_NT_PRINCIPALTargeting domain controller: dc.domain-1.comSuccessfully mapped HTTP/test.domain-2.com@DOMAIN-1.COM to wrp-testKtpass -princ HTTP/domain2test.domain-2.com@DOMAIN-2.COM -mapuser domain2test -mapOp set -crypto All -out c:\domain2test.domain-2.com.keytab -pass Madrid00 -type KRB5_NT_PRINCIPALTargeting domain controller: domctrl.domain-2.comSuccessfully mapped HTTP/domain2test.domain-2.com@DOMAIN-2.COM to domain2test
are to indicate that you can actually create the Kerberos SPN in any of the AD Domains that are participating in that Forest Trust.
First KTPASS created an SPN in DOMAIN-1.COM, representing the
https://test.domain-2.com that WebSEAL would provide SPNEGO Desktop SSO for,
and the second KTPASS in the DOMAIN-2.COM, representing the
https://domain2test.domain-2.com URL that WebSEAL would provide SPNEGO Desktop SSO for.
Since these 2 KTPASS commands result in separete keytab files to be created (one on the
dc domain controller in domain-1.com, the other on the
domctrl domain controller in domain-2.com), you'll need to combine both keytabs into a single keytab for use by WebSEAL.
Where (on which AD Domain Controller, in case of a multi-AD setup) you run the KTPASS commands, I would expect that to be AD domain where your Web Services/Infrastructure resides. (but provided that the Trusts are in place, it shouldn't really matter where).
In my (probably overly) simplified scenario I would consider CompanyA that has a set of employees in the CompanyA domain (e.g.
hans@companya.com), requiring access to
https://hr-portal.companya.com, which is a WebSEAL URL that performs SPNEGO Windows Desktop SSO.
In that case, KTPASS would be run on the Domain Controller responsible for Company A domain.
And the users in AD (cn=hans,
cn=users,dc=companya,dc=com) would be configured as Federated Users (using Federated Registry feature in ISVA)
If later on, CompanyA aquires CoolCorp (with it's own AD reponsible for CoolCorp domain) the set of users (e.g.
mohamed@coolcorp.io) will need to access the same URL
https://hr-portal.companya.com.With the
1./ AD Trusts in place,
2./ DNS zones (in the coolcorp.io domain) correctly resolving (or forwarding the DNS request to the DNS server of companya.com) the hr-prtal.companya.com Hostname
the users in AD (cn=mohamed,
cn=users,dc=coolcorp,dc=com) should be able to access
https://hr-portal.companya.com, once ISVA has also registered
cn=users,dc=coolcorp,dc=com as additional Federated Registry.
This without the need for any additional KTPASS commands.
Hope it helps?
Regards,
Hans
------------------------------
HANS VANDEWEGHE
------------------------------
Original Message:
Sent: Wed October 26, 2022 01:07 PM
From: mohamed ghonim
Subject: Configure Kerberos for multi Active directory in ISVA
Hi VANDEWEGHE,
Thanks for your support.
Kindly if you have the video of this article, it will be great because i have conflicted in two pages.
The first page number 18. He run ktpass twice, I don't know where i have to run those commands and he created ktpass with princ "domain2test.domain-2.com" and didn't use it anywhere.
The second page 19. He deleted the kerberso service name "test.domain-2.com". And added it again on page 20 so What's the right configuration?
Thanks.
------------------------------
mohamed ghonim
Original Message:
Sent: Tue October 18, 2022 02:41 AM
From: HANS VANDEWEGHE
Subject: Configure Kerberos for multi Active directory in ISVA
Hi Mohamed,
Are you talking about Authentication into ISVA using Kerberos (aka Windows Desktop SSO), or about passing user information to back-end servers using Kerberos (Constrained Delegation)?
There are a few pointers in the product documentation regarding what is needed to achieve multi AD setups for Kerberos:
https://www.ibm.com/docs/en/sva/10.0.4?topic=concepts-multiple-active-directory-domain-support
https://www.ibm.com/docs/en/sva/10.0.4?topic=wdssc-mapping-user-names-from-multi-domain-active-directory-registries
The main points to be aware of are:
- having the correct Trust relationship between the participating Kerberos AD domains. (Windows admin task)
- having DNS setup correct with forward and reverse name resolution functioning. (Windows admin task)
It's most straightforward if you also have the AD servers as 'Federated Directories'
There used to be a presentation that covers Multi AD setup with ISVA, but I can't immediately retreive the link to it. (the presentations are already a bit dated, but the parts about Multi AD are mostly still relevant)
Sharing it here in case it's of use.
Hope it helps.
Regards,
Hans
------------------------------
HANS VANDEWEGHE
Original Message:
Sent: Mon October 17, 2022 05:18 PM
From: mohamed ghonim
Subject: Configure Kerberos for multi Active directory in ISVA
Dears,
Thanks
------------------------------
mohamed ghonim
------------------------------