Manageability of larger networks

[Turbo Fredriksson]

[ Sorry for replying in public, but it reads quite loud and clear  ]
[ that I don't accept private mails about LDAP/Kerberos etc on the ]
[ HOWTO page. ]

Quoting Andreas Heilwwagen <andreas.heilwagen at jamba.net>:

> I feared that Kerberos V is not very useful for authorization. Since I
> want to implement single-sign-on for a lot of our applications I have
> chosen the software configuration explained in your LDAPv3 article/book
> project.
> 
> Hopefully I will finally put all software packages together the right way
> tomorrow. There were quite some problems to manage on a debian 3.0
> system. So afaik:
> 
>   o The applications have to use LDAP
> 
>   o LDAP uses the passwords stored in Kerberos V based on the
>      krb5 schema.

Or they do SASL directly (prefered - 'more secure').

> Can the apps still take advantage of the Kerberos tickets? I have not found
> suitable material on the net yet describing how to combine the additional
> information in the LDAP database for authorization and the Kerberos tickets
> for authentication/single-sign-on. It just looks like nearly nobody
> sets up the stuff by hand.

We're talking two (three) different (COMPLETLY) different things here.
AUTHORIZATION (I am who I say I am - Kerberos) and AUTHENTICATION (access
control). The third (semi issue) is KEEPING that information during the
life span of the application/authentication cykle (ie, while you're logged
in/the application is running).

SASL have no meens of keeping this information. This is up to the application
(ie, Kerberos tickets).

This is (roughly) how it (should) work:

1. Get a kerberos ticket
2. Authorize with SASL using the ticket

The server application (IMAPd, POPd, HTTPd or what not) asks (every time a
request is made) the LDAP server if this ticket/user have access to whatever
service is requested.

> Especially the most interesting application (openssh) has nearly no
> information on that topic (or I am totally blind...).

What _I_ do, which is not the best/most secure way is to use PAM (or SSH Krb5)
to do both authentication and authorization...

Example:

dn: uid=turbo,ou=People,dc=fredriksson,dc=com
trustModel: byserver
accessTo: papadoc.bayour.com
objectClass: trustAccount

With this information I can in LibNSS/LDAP and/or LibPAM/LDAP say (on host
papadoc.bayour.com):

nss_base_passwd         dc=com?sub?objectclass=posixAccount)(|(trustmodel=fullaccess)(accessto=papadoc.bayour.com)

This will ONLY allow connections (sorry, it isn't more fine grained than
that) IF I have 'fullAccess' _or_ if I have accessTo papadoc.bayour.com
(the hostname of the machine it's on).

This can be dangerous (as seen on a couple of hosts on the network a few days
ago). If the LDAP server isn't 'accepting searches' (ie, dead or whatever),
not even root can login on the terminal! I knew this when I sat it up, but
my view on this (for MY network) is that if the LDAP server isn't accepting
connections, nobody can do anything any way...


If I wanted to give access to ONLY IMAP/POP, this is not possible. This have
to be done in the (server) application (imapd/pop3d)...

> I would be very happy if your idea on an LDAPv3 book will become
> reality soon. In my opinion there is not enough good information currently
> available to set up a whole company using LDAP and Kerberos (although
> Kerberos V is existing for such a long time).

Thanx. I like it very much, and there are other people out there that likes it
to (I haven't had ONE negative mail - a couple of 'improvements' mails only :)

Unfortunatly for me, my English don't seem to be good enough for a book
which I find very insulting/saad because I've always been told it's VERY
good. Ah, well. It's good enough for 'daily use' I guess :)

> It would be a great help if you could point me to a ressource where I can
> find recommendations and lessons-learned concerning manageability
> issues of LDAP/Kerberos.

If you're going to do this with open source, be prepared to do _A LOT_ 
personal coding! Stealing the QmailLDAP centiment:

        This is NOT point-and-click-and-then-it-works ware

This being said, I've been running it for a couple of years (on ancient
hardware which is WAY to slow to handle the load it generates) and I'm
VERY happy with it!

Oh, not to discurrage you further, but it (LDAP/Kerberos/AFS etc) have
quite a high learning curve... :) It's not impossible, but it's complicated
and hence difficult to grasp in the beginning. I'm sure the really 
hardcore LDAP/Kerberos admins/developers here will find quite a lot
of faults with my explanation above, but this is my basic understanding
on how it works, in 'simple' words.

> Turbo Fredriksson wrote:
> 
> >Quoting Andreas Heilwwagen <andreas.heilwagen at jamba.net>:
> >
> >
> >>The ideal solution from my point of view would be to
> >>user expressions like */portaladmin@<MYREALM>
> >>to authorize a group of trusted users to administrate
> >>the java application servers.
> >>
> >
> >It's been discussed before. Kerberos is a AUTHENTICATION
> >system, not a AURHORIZATION system. For authorization,
> >use LDAP (my personal favorite).
> >
> >
> >>What concept is usually used to manage separate
> >>user groups in the Kerberos world?
> >>
> >
> >You don't. You have principals. (dot, end, no more, ende
> >etc).
> >
> >For saying 'user/application x have access to y', use
> >LDAP.
> >________________________________________________
> >Kerberos mailing list           Kerberos at mit.edu
> >https://mailman.mit.edu/mailman/listinfo/kerberos
> >