Re: Kerberos Digest, Vol 44, Issue 32 - Kerberos

This is a discussion on Re: Kerberos Digest, Vol 44, Issue 32 - Kerberos ; The lightbulb kind of came on about that after I sent off that email. Your clarification certainly helped cement that. I'm going to be using samba/winbind to provide authorization and access to local priveleges. Just a question, though, I have ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: Re: Kerberos Digest, Vol 44, Issue 32

  1. Re: Kerberos Digest, Vol 44, Issue 32

    The lightbulb kind of came on about that after I sent off that email. Your
    clarification certainly helped cement that. I'm going to be using
    samba/winbind to provide authorization and access to local priveleges.

    Just a question, though, I have one account in the non-windows KDC that can
    log into the ssh server via gssapi and it does not have a .k5login file in
    it's home directory...does this work because I have a user principal in the
    non-windows KDC? If I were to add user accounts for the Active Directory as
    principals to the non-windows KDC, would the behavior be the same? What I
    want to avoid is having to create home directories on all of our servers for
    our tech support staff just to store a .k5login file.

    Thanks for the input



    Date: Tue, 22 Aug 2006 22:30:50 GMT
    > From: Jeffrey Altman
    > Subject: Re: Windows GSSAPI ssh connection via cross-realm
    > authentication
    > To: kerberos@MIT.EDU
    > Message-ID:
    >
    > Jason:
    >
    > I think you misunderstand the role of Kerberos here. Kerberos is being
    > using to authenticate the user by name. If the SSH service is in realm
    > "A.EXAMPLE.COM" and the user is in realm "B.EXAMPLE.COM", the after
    > successful authentication the SSH service knows the name as something
    > like "name@B.EXAMPLE.COM". The question that then must be answered is
    > this:
    >
    > Is name@B.EXAMPLE.COM authorized to access this account on this
    > machine?
    >
    > The answer to that question is an authorization decision and it is made
    > independently of the KDCs for A.EXAMPLE.COM. The default method
    > provided in the Kerberos libraries is to perform a lookup in a file
    > ~/.k5login to see if the authenticated name is listed. You can replace
    > this mechanism with one of your own choosing but it requires that the
    > Kerberos function krb5_kuserok() not be used to make the authorization
    > decision by the application.
    >
    > Jeffrey Altman
    >
    >
    >
    >

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


  2. Re: Kerberos Digest, Vol 44, Issue 32

    The reason that user@A.EXAMPLE.COM is able to login to account "user"
    via SSH is because the SSH service exists in the realm A.EXAMPLE.COM.
    Therefore, user@A.EXAMPLE.COM is assumed to be the same entity as "user".

    The same assumption cannot be made for user@B.EXAMPLE.COM.

    Jeffrey Altman


    Jason Mogavero wrote:
    > The lightbulb kind of came on about that after I sent off that email. Your
    > clarification certainly helped cement that. I'm going to be using
    > samba/winbind to provide authorization and access to local priveleges.
    >
    > Just a question, though, I have one account in the non-windows KDC that can
    > log into the ssh server via gssapi and it does not have a .k5login file in
    > it's home directory...does this work because I have a user principal in the
    > non-windows KDC? If I were to add user accounts for the Active Directory as
    > principals to the non-windows KDC, would the behavior be the same? What I
    > want to avoid is having to create home directories on all of our servers for
    > our tech support staff just to store a .k5login file.
    >
    > Thanks for the input
    >
    >
    >
    > Date: Tue, 22 Aug 2006 22:30:50 GMT
    >> From: Jeffrey Altman
    >> Subject: Re: Windows GSSAPI ssh connection via cross-realm
    >> authentication
    >> To: kerberos@MIT.EDU
    >> Message-ID:
    >>
    >> Jason:
    >>
    >> I think you misunderstand the role of Kerberos here. Kerberos is being
    >> using to authenticate the user by name. If the SSH service is in realm
    >> "A.EXAMPLE.COM" and the user is in realm "B.EXAMPLE.COM", the after
    >> successful authentication the SSH service knows the name as something
    >> like "name@B.EXAMPLE.COM". The question that then must be answered is
    >> this:
    >>
    >> Is name@B.EXAMPLE.COM authorized to access this account on this
    >> machine?
    >>
    >> The answer to that question is an authorization decision and it is made
    >> independently of the KDCs for A.EXAMPLE.COM. The default method
    >> provided in the Kerberos libraries is to perform a lookup in a file
    >> ~/.k5login to see if the authenticated name is listed. You can replace
    >> this mechanism with one of your own choosing but it requires that the
    >> Kerberos function krb5_kuserok() not be used to make the authorization
    >> decision by the application.
    >>
    >> Jeffrey Altman
    >>
    >>
    >>
    >>

    > ________________________________________________
    > Kerberos mailing list Kerberos@mit.edu
    > https://mailman.mit.edu/mailman/listinfo/kerberos
    >


  3. Re: Kerberos Digest, Vol 44, Issue 32

    >>>>> "Jeffrey" == Jeffrey Altman writes:

    Jeffrey> The same assumption cannot be made for
    Jeffrey> user@B.EXAMPLE.COM.

    Although if this assumption is true in your environment the
    aname_to_localname rules (see the admin guide) will allow you to
    configure this behavior.

    --Sam

    ________________________________________________
    Kerberos mailing list Kerberos@mit.edu
    https://mailman.mit.edu/mailman/listinfo/kerberos


+ Reply to Thread