Thanks John.
I have made a setup like this
DomainA (forest) DomainB(forest)
DomainA trusts DomainB and not vice-versa. So DomainA is trusting domain
and DomainB the trusted domain.
With this, can I
1. use DoaminB\user0 user to log on to a machine added to DomainA
2. access a service on DomainA using DomainB\user0?
If NTLMv2 is used in this case, does DomainA gets challenge/response
tokens generated in the process
validated by DomainB? Does anything special needs to be setup for this
to work?
~ Nathan
On Wed, Mar 6, 2013 at 2:52 PM, John Baker
<jba...@javasystemsolutions.com>wrote:
> Hello,
>
> If two domains are in a trust relationship, you can configure a product
> to authenticate NTLMv2 tokens against one and it'll handle tokens from
> the second domain. Unfortunately, AtriumSSO is the OpenSSO/AM product
> with a BMC badge and has no Integrated Windows Authentication module,
> and to make just Kerberos work is not only difficult, but often
> unreliable. Some chap from BMC made a video on how to configure
> AtriumSSO with Kerberos and admitted himself that it's not reliable. I
> believe the video is on BMC DN somewhere.
>
> This topic is difficult because few companies have tried very hard to
> build a Java IWA adapter: large specialist SSO companies such as Ping
> still supply bits of one, and Quest's old Kerberos+NTLMv1 (note, not
> secure) adpater is still being flogged (although I heard they may have
> an NTLMv2 component at some point). And even when both Kerberos+NTLMv2
> are glued together, there are lots of edge cases (Negotiate Extensions,
> NTLM wrapped in SPNEGO tokens [that most people think is a Kerberos
> token; it's not], NTLM tokens without domain names - or even curiously,
> bits of an SPN that puzzle even me.
>
> Typically, people can get "most users" working with a non-IWA solution
> but will find a aubset of users can't authenticate correctly,
> particularly those connecting from VPN solutions, and hence support
> becomes a headache (plus it's embarrassing for the person who
> implemented/paid for it).
>
> The most common non-Java route is to put an IIS Instance in front of
> Tomcat, but this means the SSO token is being decoded at IIS and not in
> the web application, which many penetration testing/security related
> outfits would not admire. I know of at least one BMC Elite Partner
> knocking out this "solution" to unsuspecting customers who end up paying
> a lot of money for a dirty solution.
>
> JSS felt a lot of pain some years ago when we tried the Kerberos only
> route, and quickly realised we needed to invest heavily in a reliable
> IWA adapter. It's in use by many of BMC's largest clients today, and has
> quickly begun to gain traction in entirely different markets: most
> recently, an adapter for the Jive Software solution that powers BMC DN.
>
> Adding to all of this, there's a lot more to quality SSO solution than
> making iWA work with the BMC product set: What happens if two users
> deaster exists in domains A and B, one with deaster and the other as
> deaster2 as AR System Login Names? What about the different user
> repositories in each BMC product - do you want to manage each
> separately? Users without accounts in ITSM, etc, etc.
>
> AREA LDAP is of course plain old LDAP and not in scope.
>
>
> John
> --
> SSO Plugin for BMC ITSM, and more.
> http://www.javasystemsolutions.com/jss/ssoplugin
>
>
> _______________________________________________________________________________
> UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
> "Where the Answers Are, and have been for 20 years"
>
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at www.arslist.org
"Where the Answers Are, and have been for 20 years"
