IBM Verify

IBM Verify

Join this online user group to communicate across Security product users and IBM experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.

 View Only

  • 1.  KCD thoughts

    Posted 06/07/19 02:11 AM
    Hi community,

    Kerberos constrained delegation (KCD), is a great way to get SSO between webseal and a backend server.
    However, if I am not mistaken, it requires a connection to the AD servers.

    I have mixed feelings about that: it seems not great to open a connection from right of the edge of the DMZ all the way to the AD servers that are pretty deep in the network and usually host quite "interesting" information.

    Is there a way to have a 2-tier setup for this, so that WebSEAL does not need to talk directly to the KDC?
    If there's not, what is your view on this subject?

    Kind regards

    ------------------------------
    Kristof Goossens
    ------------------------------


  • 2.  RE: KCD thoughts

    Posted 06/07/19 06:12 AM
    Hi Kristof,

    Although Kerberos tokens can be accepted without a connection to a KDC, you are correct that for generation of tokens a connection to KDC is required.

    A few ideas on architecture - to be debated:

    • I wonder if 2 tiers of SAM Reverse Proxies could be used.  First layer performs authentication and down-streams identity to seond tier (in more protected zone).  The second tier of Reverse Proxies have the junctions to Microsoft endpoints and perform the Kerberos SSO.  I would worry about making the proxying more complex but could be an answer.
    • I'm not that familiar with AD architecture but perhaps a Domain Controller could be put in an isolated segment with connectivity to rest of AD downsteam but only connectivity on Kerberos ports from DMZ.  Would make things better?
    I know lots of people use this SSO capability so comments on in-use architectures for this from other community members would be very interesting to hear.

    Jon.

    ------------------------------
    Jon Harry
    Consulting IT Security Specialist
    IBM
    ------------------------------



  • 3.  RE: KCD thoughts

    Posted 06/08/19 01:16 AM
    Hi John,

    In our architecture, we have a frontend cluster and a backend cluster.

    The frontend cluster is positioned in a DMZ and hosts WebSEAL and some publicly accessable endpoints like the LRR endpoints etc.

    The backend cluster is a bit more sealed off and hosts services that are only available to components from the frontend server and hosts an EAI application that is allowed to connect to more secure components (DB, AD, LDAP, Webservices, etc).

    Your first solution appeals to me (adding an extra RP does not really complicates that much for us, as we have quite more complex stuff going on in our environment :) ), but I'm wondering where to position the second WebSEAL in that case. Hosting it in the backend cluster doesn't really seem the nicest solution because the production traffic to the application would than be routed through the backend cluster.

    We might think of creating some sort of third zone specifically for that, but that doesn 't feel great either.

    It's becoming a bit of a theoretical discussion, because you are right in pointing out that it is only the kerberos communication, which already brings down the severity of "the issue".

    In an ideal world, we could have some kind of "smart proxy" between webseal and the applications that require KCD. That one could receive the identity of the user as well as the realm to authenticate that user in and with that information reach out to some microservice in the backend cluster that will fetch tickets and deliver tokens to that "smart proxy".

    That proxy could treat those tokens as opaque values and just inject them in the authorization header. Maybe the microservice could also return the lifetime of the tokens in order for it to know when to request new tokens without having to understand the tokens itself (so it can treat them as opaque values).

    It's very much similar to the way we work today where WebSEAL contacts the STS module of TFIM to translate a PAC file to a (set of) kerberos tokens, I guess.

    What's your idea on such a setup?

    ------------------------------
    Kristof Goossens
    ------------------------------

    Original Message


  • 4.  RE: KCD thoughts

    Posted 06/10/19 03:29 AM

    Hi Kristof, 

    Another approach, depending on your overall security architecture, could be to utilise some more of the Microsoft functionality that is already available, namely the RODC (Read Only Domain controller).

    With RODC, you should be able to set these up with a limited attribute set so that you are not exposing any "interesting" information, for instance you could remove, names, grades etc from the Schema so that these are not replicated to the RODCs, the same with passwords, and I believe from previous experience (limited) that when a request to verify a password is passed to a RODC, while removed from the attribute set, it forwards the request onto a Writable Domain controller.
    So this will allow you to move some of the Domain controllers up the Security layer stack, as of course they would contain a limited set of data; without compromising functionality. 


    Below is a link to an older article relating to Win 2008; however the same concepts should be possible in the later OSes.
    https://docs.microsoft.com/en-us/windows/desktop/ad/rodc-and-active-directory-schema

    Hope this helps, or at least furthers the discussion. 



    ------------------------------
    David Hall
    ------------------------------

    Original Message


  • 5.  RE: KCD thoughts

    Posted 06/10/19 04:01 AM
    Hey David,

    That's actually very interesting! I had no clue about the existence of that feature.

    The AD is not in control of our team, but we'll get in discussion with the responsible team about it. It could be equally interesting to connect to such a read only system just to consume attributes from the AD LDAP in my opinion.

    Thx

    ------------------------------
    Kristof Goossens
    ------------------------------

    Original Message


  • 6.  RE: KCD thoughts

    Posted 06/10/19 04:23 AM

    Hi Kristof, 

    Happy to help!

    Indeed, we use the RODC's in the same fashion, to allow some of our internal applications which are hosted in different security zones to consume AD information and to allow the generation of Kerb tokens - this also should work for things like ADFS (Active Directory Federation Services), which also can hook into ISAM quite simply; of course, if you are using the Federation side of things. 

    Let me know how you get on. 

    Cheers,
    Dave



    ------------------------------
    David Hall
    ------------------------------

    Original Message


Related Content