Re: SSO - Kerberos

This is a discussion on Re: SSO - Kerberos ; "Michael B Allen" writes: > On Thu, Jul 17, 2008 at 5:01 PM, Russ Allbery wrote: >> Well, no, they're double sign-on because the central server usually has >> to prompt you for a password. But if the central server ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: SSO

  1. Re: SSO

    "Michael B Allen" writes:
    > On Thu, Jul 17, 2008 at 5:01 PM, Russ Allbery wrote:


    >> Well, no, they're double sign-on because the central server usually has
    >> to prompt you for a password. But if the central server implements
    >> Negotiate-Auth and the browser speaks it, both WebAuth and Cosign give
    >> you true and complete single sign-on.


    > But only if clients are members of the domain.


    Well, possessing Kerberos tickets in the domain, at least. (If you use
    Firefox, you don't have to actually be a member of the domain; you can use
    a different mechanism for getting Kerberos tickets, such as NIM.) But
    essentially yes.

    > And that is the scenario where direct SPNEGO / NTLMSSP solutions are
    > going to perform better.


    If by "better" you mean "pretty much the same," yes, modulo the
    configuration note that I mentioned.

    > I believe you mean that you have to add something to "IE > Security >
    > Local intranet" or the "network.negotiate-auth.trusted-uris" in FF? You
    > do not have to specify each server explicitly. Those configs accept
    > domain suffixes.


    Correct. And if that's easy for you to do for all sites of interest, then
    that's great. It is in some cases and not in others.

    >> The password prompting behavior from an IIS server to Firefox and
    >> similar browsers is also poor and confusing in our experience, but that
    >> may be fixable.

    >
    > This is a little bit of a stretch. It might be true for mod_auth_kerb
    > but otherwise, it's basically false.


    I'm not sure why you raise mod_auth_kerb when I specifically mentioned
    IIS. It's been an issue for us with IIS and Negotiate-Auth.

    > IIS will do NTLMSSP if the client does not want to or cannot do
    > SPNEGO. If that fails (e.g. because the client is not logged in with
    > domain credentials) then the browser will pop up a password dialog but
    > it will still do NTLMSSP with the creds entered.


    Correct, and our experience is that, when this happens, the dialog box
    presented by the browser often doesn't work correctly and requires that
    the user press Enter to get a second password dialog box, depending on
    what negotiation the browser tries to do. The user may also need to enter
    a different form of their account name (prefixed with the AD realm, for
    instance) depending on the local configuration.

    As I say, these issues may be addressable, but I know that they've been
    very confusing for users in our environment and have been a definite
    negative in doing Negotiate-Auth directly with IIS for us. I haven't been
    directly involved in trying to fix them, but I know that we've deployed
    some services using pure Negotiate-Auth on IIS and tried for some time to
    address this, finally giving up and just documenting the behavior for our
    users.

    > In our Plexcel product, we provide a script level API which provides a
    > major advantage over IIS, WebAuth, mod_auth_kerb or anything else that
    > intercepts requests. So with Plexcel, if the client cannot do SPNEGO,
    > the script can decide what to do which is usually to redirect the user
    > to an SSL protected HTML login form where they then use Plexcel's API
    > again to do a Kerberos 5 login.


    Yes, this is easier with Negotiate-Auth (although only Negotiate-Auth is
    needed; your product isn't). It's standard Apache functionality (using
    error handlers for failed authentications) available to any authentication
    module, but it doesn't work for authentication modules that never fail,
    only redirect the user (WebAuth and Cosign both fit this model).
    mod_auth_kerb can fail, letting error handlers do their job.

    Shibboleth offers another solution to this problem (lazy sessions) which
    has its pluses and minuses compared to using failure handlers.

    In brief, the main advantages that something like WebAuth or Cosign offer
    is centralizing the handling of the Negotiate-Auth process on a single
    system (which may or may not simplify browser configuration depending on
    your environment) and a fallback mode that, in the absence of SPNEGO
    Negotiate-Auth, is closer to single sign-on than you would get by running
    Negotiate-Auth separately on each web server. What you lose is the
    additional complexity of setting up the WebAuth or Cosign infrastructure,
    including the need for a central UNIX server, and in the case of WebAuth,
    IIS support (making it unsuitable for the problem originally presented on
    this thread).

    --
    Russ Allbery (rra@stanford.edu)

  2. Re: SSO

    Russ Allbery wrote:
    > (If you use
    > Firefox, you don't have to actually be a member of the domain; you can use
    > a different mechanism for getting Kerberos tickets, such as NIM.)


    What is NIM?

    Ciao, Michael.

  3. Re: SSO

    Michael Ströder writes:
    > Russ Allbery wrote:


    >> (If you use Firefox, you don't have to actually be a member of the
    >> domain; you can use a different mechanism for getting Kerberos tickets,
    >> such as NIM.)


    > What is NIM?


    Network Identity Manager, although properly speaking the bit that's
    actually getting the tickets is Kerberos for Windows. NIM is the UI and
    an abstraction layer that can handle additional types of credentials.
    This is what we use for nearly all of our Windows clients to avoid having
    to have them all joined to a domain (which in many cases is just not an
    option).

    --
    Russ Allbery (rra@stanford.edu)


+ Reply to Thread