Re: Distributed authentication. Which one?

From: Tillman Hodgson (tillman_at_seekingfire.com)
Date: 10/18/05

  • Next message: Boris Samorodov: "Re: have a question"
    Date: Tue, 18 Oct 2005 09:09:06 -0600
    To: Francisco <francisco@natserv.net>
    
    

    On Tue, Oct 18, 2005 at 10:37:53AM -0400, Francisco wrote:
    > On Mon, 17 Oct 2005, Tillman Hodgson wrote:
    >
    > >It has some interoperability and security issues. They're solvable, IMO.
    >
    > Thanks for the feedback.
    >
    > I guess a good test is to ask.. what would you use? :-)

    On a meta-network (http://metanetwork.seekingfire.com/wiki.pl) we've
    used Kerberos with cross-realm trusts in combination with NIS providing
    the meta information (preferred shell, etc) for "users in common"
    (non-local). It maps well to multiple administrative domains.

    On purely local networks where the number of users are low (a few dozen
    at most), I like using something like cfengine to simply keep all local
    user databases in sync. I then use Kerberos (preferred) or sudo to break
    out root-like powers in an auditable way.

    I'm a fan of IPsec transport mode with the blowfish algorithm and
    compression turned on -- it's "good enough" security for my needs and
    can actually /increase/ the effective bandwidth (I've posted the results
    of a Sun Ultra5 and a few Intel box to FreeBSD mailing lists in the past,
    ithe archives should have them somewhere). The fact that it makes using
    traditional RPC services a bit more secure is merely a bonus :-)

    > >For example, most of the security concerns can be addressed with a
    > >combination of transport-mode IPsec and Kerberos and I avoid inter-
    > >operability issues by avoiding weird implementations of NIS ;-)
    >
    > Sounds like more trouble than it's worth.

    You'll likely find that there's similar issues for any cross-platform
    solution with decent security. I'd use whatever you can best understand,
    since anything security related that works but isn't well understood can
    be a source of future problems. If you grok LDAP, then use LDAP :-)

    > Right now I am leaning towards Kerberos or LDAP.

    They're differnet things. Kerberos *and* LDAP is a nice combination.

    Kerberos is for /authentication/, and authentication only. It doesn't
    handle meta data (like home dir, shell, group information, etc) and it
    handles authorization only in passing and not in a finely-grained manner
    (via .k5login, basically). It does authentication exceedingly well and
    that's what I consider its prime attraction.

    So when considering Kerberos it generally makes sense to design the user
    management system to be Kerberos + $somthing_else. The $something_else
    provides the meta-data, group information and authorization pieces of
    the puzzle.

    This isn't as convoluted as it sounds. Take web services for example --
    the required meta data is often different than for local users, but the
    concept of secure authentication remains the same. Think of it as
    flexibility rather than complexity.

    > Need to learn more about them to see their strengths and weaknesses and
    > how it would fit into our existing extructure.

    I have a very basic (albeit somewhat old) presentation on Kerberos up at
    http://www.seekingfire.com/documents/presentations/kerberos_presentation/kerberos.pdf,
    and a collection of useful links at
    http://www.seekingfire.com/projects/kerberos/. There's a variety of
    HOWTOs floating around the net on combining Kerberos with local passwd
    files, NIS, LDAP, and other user database technologies.

    There's also the O'Reilly book, which is handy but not as comprehensive
    as I'd like (http://slashdot.org/comments.pl?sid=139450&cid=11672353 has
    my original comments archived).

    -T

    -- 
    "What are the facts, and to how many decimal places? You pilot always
     into an unknown future; facts are your only clue. Get the facts!"
        -- Lazarus Long (_Time Enough for Love_, Robert Heinlein)
    _______________________________________________
    freebsd-isp@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-isp
    To unsubscribe, send any mail to "freebsd-isp-unsubscribe@freebsd.org"
    

  • Next message: Boris Samorodov: "Re: have a question"

    Relevant Pages

    • RE: Kerberos OpenLDAP Frontend
      ... I'm developing a Master Thesis and I'm mounting a security infrastructure. ... One pillar of this is Kerberos and ldap. ... We've got a free and open source solution called NetDirector that attempts ...
      (comp.protocols.kerberos)
    • [NEWS] Cisco VPN 3000 Kerberos Authentication Implementation Remote Code Execution And DoS
      ... Get your security news from a reliable source. ... over IPSec, and Cisco WebVPN ... Kerberos Key Distribution Center may be vulnerable to remote code ... The second vulnerability consists of an infinite loop in the Abstract ...
      (Securiteam)
    • Re: UserName and Kerberos tokens at the same time
      ... \par My client is a Windows application and I can se that the kerberos token is ... The kerberos Security token will try establish the security ... \par> Steven Cheng ... \par> Microsoft Online Support ...
      (microsoft.public.dotnet.framework.webservices.enhancements)
    • Using Kerberos enabled connections with Sybase
      ... I am attempting to connect to a 12.5 Sybase server using kerberos enabled connections. ... My isql and sqsh both correctly connect (sqsh needed a small fix to load the security). ...
      (perl.dbi.users)
    • Re: Security in Cubes and Dimension
      ... You may need to build application-level security logic into your IIS ... unless you can use Kerberos to pass UserID: ... Microsoft SQL Server 2000 Analysis Services Operations Guide ...
      (microsoft.public.sqlserver.olap)