Cichlidiot wrote:
> Since you're making unsubstantiated claims on this thread, let me throw in
> mine.... Practical, hahaha.

Whatever you think dude...
However, I'm still waiting for a decent replacement solution.

On Thu, 18 Nov 2004 16:55:32 +0100, Antoine Jacoutot wrote:
> Menno Duursma wrote:
>
>> There are more ways to most ends (for instance: SSL/TLS). And whatever,
>> with the implementation flaws in MIT Kerberos as of late... I use Heimdal:
>
> I do too.
> But tell me, how do you manage to login at the console if your
> authentication is Kerberos ?

Uuh? Is some kind of trick question?
(As "the console" would be for _local_ administration as "root" user...)

$ grep -m1 heimdal /etc/inittab
c4:1235:respawn:/sbin/agetty 38400 tty6 -l /usr/heimdal/bin/login

> By they way, for password management, NIS is not an option for me.

Then don't use it for that... You could still use it for the GCOS stuff
ofcource. Just edit /etc/nsswitch.conf appropriately then...

--
-Menno.

On Fri, 19 Nov 2004 08:30:58 +0100, Antoine Jacoutot wrote:
> Cichlidiot wrote:

[ About PAM ]

> However, I'm still waiting for a decent replacement solution.

For network services: SASL
For client stuff -> recompile ... ( Or maybe install Dropline GNOME .)

--
-Menno.

On Thu, 18 Nov 2004 18:17:51 +0100, Antoine Jacoutot wrote:
> Keith Keller wrote:
>> If by securely you mean encrypted, then you are completely incorrect.
>
> No, I did not mean that.

Well, i agree with you here. Ie: using a ticket (lasting 8 hours or less)
rather then sending a password or cert with a relatively "long" lifetime
over the wire, is good. So even if the trafic is captured, and decoded
offline, the ticket would be useless at that point.

>> I have configured a Slackware client to use TLS to initate an SSL
>> connection with an OpenLDAP server when authenticating via LDAP
>> configured through NSS. No PAM or Kerberos is required.

But then it's not as secure either...

> But anyway, what I'm interested in is Kerberos support which is not
> available without first installing heimdal or MIT

Or Shishi (which i haven't tried (yet)):
http://josefsson.org/shishi/

> then, recompiling all packages you want them to be kerberos aware.

Which is probably just one or two, per machine. Hence not much more work
then setting up PAM correctly, however much more secure (and likely robust.)

> If PAM was included, it would be much easier.

IMO only for some workstations. As for basic corporate desktop and server
machines, they just are imaged. So you only have to setup one, and rollout.

--
-Menno.

Menno Duursma wrote:
> Uuh? Is some kind of trick question?
> (As "the console" would be for _local_ administration as "root" user...)

What about user workstations ?

On Sat, 20 Nov 2004 10:24:28 +0100, Antoine Jacoutot wrote:
> Menno Duursma wrote:
>> Uuh? Is some kind of trick question?
>> (As "the console" would be for _local_ administration as "root" user...)

To clear this up: the kerberized "login" provided with Heimdal tries to
autenticate "root" only to the local /etc/shadow file.

> What about user workstations ?

Well, just copy over the /bin/login and create principals for them with
"kdamin"... IOW read:

info heimdal

First thing after installation and just follow the instructions there.

Surely i have created a lot more service principals then would strictly be
needed, so i cant realy help you with which ones to "add" and "ext" ...
However, it shouldn't be to hard doing "tail -f /var/heimdal/kdc.log" in
one "xterm" and "kadmin -l" in some other. While doing Crtl-Alt-F6/F7
switching after failed login. You might want to "passwd -l <someuser>" so
you'll know when login works, it's autenticated via Kerberos.

If you have any trouble with this, post the output of: "ktutil list"
(Hostnames, realm, /etc/hosts (or DNS records) are you using NTP? etc)

PS: The NIS suggestion i posted was sort of a joke ;-)
If it's just a couple of machines, just "rsync" passwd and group files
Otherwise i'd look into LDAP.
HTH -Cheers.

--
-Menno.

On Sat, 20 Nov 2004 15:47:33 +0000, Menno Duursma wrote:
> On Sat, 20 Nov 2004 10:24:28 +0100, Antoine Jacoutot wrote:
>> Menno Duursma wrote:

[ Replying to my own post, but i seem to have forgot something (yet again). ]

>>> Uuh? Is some kind of trick question?
>>> (As "the console" would be for _local_ administration as "root" user...)
>
> To clear this up: the kerberized "login" provided with Heimdal tries to
> autenticate "root" only to the local /etc/shadow file.

Which is probably the only user you want in there too.

>> What about user workstations ?
>
> Well, just copy over the /bin/login and create principals for them [...]

And don't forget to create ~/.k5login and/or ~/.klogin containing:

user@REALM.LAN

(Where "user" is the principal- and account- name and "REALM.LAN" your
realm (here with my little home network it is: TEST.LAN .))

Have fun.

--
-Menno.

On Thu, 18 Nov 2004 02:52:42 +0000, +Alan Hicks+ wrote:

> Slackware does not nor has it ever included PAM. Pat has thought over
> this decision many times and like all decisions concerning Slackware,
> it's primarily a technical one. I won't go into those reasons here, but

Why not? As i, for one, am interested to know...
(Sorry 'bout late reply.)

Personally i think it too complex to have even a remote chance of being
securely implemented. Furthermore even the very concept of having a
tolken->PAM->autentication service doesn't exectly look very
trustworthy when compared tolken->autentication service to me...
Then there is the dynamic loading of another back-end which is a feature
on the one-hand but a liability on the other.

Obviously it does have some merit for distro builders and consultants
that need to support a mix of whichever (legacy) autentication scheme(s).

Still, for network services SASL is way superior at that, as it just
negotiates a scheme to use, and passes the actual processing of that to a
library supported directly. For two (free) implementations:
http://www.gnu.org/software/gsasl/
http://asg.web.cmu.edu/sasl/

However, Slackware doesn't include (one of) those either. Which leaves
(re)compiling stuff, if you want/need any scheme un-suported OOTB. Maybe
not too big a deal for administator type of people, but more effort then
some MCSE type of lusers could/might be expected to handle...

Now particularly with MS-Windows 2k/2k3 , using Kerberos 5 as it's native
authentication scheme (plus Krb5 being the most secure, out of the readily
available for Unix, time tested, with HA capability, etc). To me it would
seem: if you're going to support any /one/ form of SSO (single-sign-on) ...

--
-Menno.

On 2004-11-20, Menno Duursma <pan@desktop.lan> wrote:
> On Thu, 18 Nov 2004 02:52:42 +0000, +Alan Hicks+ wrote:
>
>> Slackware does not nor has it ever included PAM. Pat has thought over
>> this decision many times and like all decisions concerning Slackware,
>> it's primarily a technical one. I won't go into those reasons here, but
>
> Why not? As i, for one, am interested to know...
> (Sorry 'bout late reply.)
>
> Personally i think it too complex to have even a remote chance of being
> securely implemented.

That's Pat's answer, in a nutshell. IIRC a more complete answer
was posted to the newsgroup a while back.

The SASL URLs you posted look interesting; I'll have to read them
more carefully some time.

--keith

--
kkeller-usenet@wombat.san-francisco.ca.us
(try just my userid to email me)
AOLSFAQ=http://wombat.san-francisco.ca.us/cgi-bin/fom