On Monday, January 16, 2006 09:48:18 AM +0100 Rainer Toebbicke
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman wrote:
Those tools are deprecated, and IMHO a pagsh.krb5 would be
inappropriate, unless we plan on shipping a complete suite of tools that
manage krb5 tickets, as we did for krb4.
Jeffrey Hutzelman wrote:
Those tools are deprecated, and IMHO a pagsh.krb5 would be
inappropriate, unless we plan on shipping a complete suite of tools that
manage krb5 tickets, as we did for krb4.
Guess what Heimdal's pagsh does?
I follows the do-what-I-mean principle, in this case a ne
> Yeah, currently you have to be careful to start sshd outside of a PAG
> when using libpam-openafs-session (with, for instance, "echo
Plus you need to make sure, your users end up in session-specific pag's.
While this is not strictly necessary, it's quite inconvenient to have two
(possibly unrela
Juha Jäykkä <[EMAIL PROTECTED]> writes:
>> Red Hat's pam_krb5 is not alone in having this problem;
>> see Debian bug #264902.
> Thanks. This looks like exactly what I experienced. I never tried logging
> in as another user, though, but since my shell got in the same PAG as
> sshd, I assume the o
> Red Hat's pam_krb5 is not alone in having this problem;
> see Debian bug #264902.
Thanks. This looks like exactly what I experienced. I never tried logging
in as another user, though, but since my shell got in the same PAG as
sshd, I assume the other user logging in through the same sshd would
> It and its friends can be found at ftp://achilles.ctd.anl.gov/pub/DEE
> pam_afs2-0.1.tar
> gafstoken-0.3.tar
> gssklog-0.11.tar
This is the beast I was referring to. I'm sorry I was too lazy to check
who created it and properly credit you.
> The design goals of all of this was to keep AFS as fa
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
> Those tools are deprecated, and IMHO a pagsh.krb5 would be
> inappropriate, unless we plan on shipping a complete suite of tools that
> manage krb5 tickets, as we did for krb4.
The problem is, pagsh.krb5 is a program that should alter both AFS and
K
On Fri, 13 Jan 2006 09:12:14 +0200
Juha Jäykkä <[EMAIL PROTECTED]> wrote:
> > > I think that pam_krb5afs.so no longer exists, [...]
> > pam_krb5afs exists at least in Debian for Heimdal clients. I have a
few
> > machines with Heimdal running it now, and it appears to work fine.
>
> And in which p
On Friday, January 13, 2006 11:00:14 AM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
Sergio Gelato <[EMAIL PROTECTED]> writes:
I also like it that Heimdal's pagsh (kpagsh, in Debian) will generate a
new KRB5CCNAME, so that a subsequent kinit will not clobber the Kerberos
ccache of the par
On Thursday, January 12, 2006 06:41:21 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
However, they do it that way not as part of some misguided attempt at
"security", but because of the constraints imposed by the way their SSH
protocol parse
Juha Jäykkä <[EMAIL PROTECTED]> writes:
> Debian's pam_krb5.so (where does this originate from?)
http://www.squishy.cc/software/pam-krb5/
> Will leak tokens (not create a PAG) when authenticating with pubkey
This isn't a problem that pam-krb5 should be solving; instead, it should
be dealt with
Juha Jäykkä wrote:
I would like to see the OpenAFS people pick this up and distribute the
pam_afs2 or its equivalent with OpenAFS, as it is only used by AFS. The
discussions on the list lately are headed this way.
I support that idea. It is the only pam module which does things the Right
Wa
> I would like to see the OpenAFS people pick this up and distribute the
> pam_afs2 or its equivalent with OpenAFS, as it is only used by AFS. The
> discussions on the list lately are headed this way.
I support that idea. It is the only pam module which does things the Right
Way(tm). I did some te
Sergio Gelato <[EMAIL PROTECTED]> writes:
> I also like it that Heimdal's pagsh (kpagsh, in Debian) will generate a
> new KRB5CCNAME, so that a subsequent kinit will not clobber the Kerberos
> ccache of the parent process. OpenAFS's pagsh shouldn't (and doesn't) do
> that since OpenAFS tries to be
Juha Jäykkä wrote:
It and its friends can be found at ftp://achilles.ctd.anl.gov/pub/DEE
pam_afs2-0.1.tar
gafstoken-0.3.tar
gssklog-0.11.tar
This is the beast I was referring to. I'm sorry I was too lazy to check
who created it and properly credit you.
The design goals of all of this was
* Juha Jäykkä [2006-01-13 09:05:09 +0200]:
> As what comes to kinit, its not setting the pag is a surprise to me after
> all the praise of Heimdal's supposedly good integration with AFS.
Sometimes you want to start a new PAG, and sometimes you want to add or
refresh credentials in your current PA
On Thu, 12 Jan 2006 00:08:50 +0200
Juha Jäykkä <[EMAIL PROTECTED]> wrote:
> I think that pam_krb5afs.so no longer exists, [...]
pam_krb5afs exists at least in Debian for Heimdal clients. I have a few
machines with Heimdal running it now, and it appears to work fine.
-zeroguy
___
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
> However, they do it that way not as part of some misguided attempt at
> "security", but because of the constraints imposed by the way their SSH
> protocol parser interacts with keyboard-interactive. Fixing it would
> require significant work, not to
On Thursday, January 12, 2006 04:15:08 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
In fact, if you're using OpenSSH 4.2 and aren't building with the
(unsupported and strongly discouraged by upstream) threading hack, any
setpag() done in the authentication phase *definitely won't* affect
Sergio Gelato <[EMAIL PROTECTED]> writes:
> If you're using privilege separation in OpenSSH, the setpag() that's
> done in the authentication phase may not affect the user session (unless
> they've managed to make that process a descendant of the one in which
> the authentication takes place, or p
* Juha Jäykkä [2006-01-11 13:19:57 +0200]:
> > > I would have thought pam_krb5.so [1] does this by itself, but
> > It's only a PAM module for Kerberos. It doesn't know anything about
> > AFS.
>
> I disagree. From its README:
>
> o tokens
> Create a new AFS PAG and obtain AFS tokens during the
Juha Jäykkä wrote:
Suggestions?
I have one: there is such a thing as pam_afs2.so, which I found somewhere,
which can run arbitrary programs as part of PAM login process (at auth
stage, if I recall). It can do afslog (and it even comes with its own
afs5log of which I know nothing) instead of
> about AFS, or PAGs. But some do, so look for a pam_krb5afs.so
I think that pam_krb5afs.so no longer exists, at least the README of
RedHat's pam_krb5.so says
This is a major rewrite of pam_krb5afs. Call it 2.0, for lack of a better term.
o Compared to the earlier releases, this tree builds a s
> Ah, okay, I didn't realize that.
It's the best working solution I have been able to come up with. Its being
monolithic makes it non-ideal, but it seems to work fine. It even parses
krb5.conf's [appdefaults] pam = { ... } and is easy to configure. It even
allows me to set non-default renew_timeou
> > I would have thought pam_krb5.so [1] does this by itself, but
> It's only a PAM module for Kerberos. It doesn't know anything about
> AFS.
I disagree. From its README:
o tokens
Create a new AFS PAG and obtain AFS tokens during the authentication
phase. By default, tokens are obtained for
Russ Allbery wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
No it doesn't. All it needs is a relatively simple library which
provides a way to check for the presence of AFS and to make AFS system
calls, particularly setpag and pioctl.
Conveniently, heimdal comes with such a librar
On Wednesday, January 11, 2006 04:00:47 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
Russ Allbery <[EMAIL PROTECTED]> wrote:
Certainly such a library would be useful. If someone wants to
implement it without all of the dependencies that
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> wrote:
>> Certainly such a library would be useful. If someone wants to
>> implement it without all of the dependencies that Heimdal libkafs has,
>> I'd be all in favor of it. Heimdal's libkafs has significant
>> de
On Wednesday, January 11, 2006 03:15:56 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
No it doesn't. All it needs is a relatively simple library which
provides a way to check for the presence of AFS and to make AFS system
calls, particularl
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
> No it doesn't. All it needs is a relatively simple library which
> provides a way to check for the presence of AFS and to make AFS system
> calls, particularly setpag and pioctl.
> Conveniently, heimdal comes with such a library; it's called libkaf
On Wednesday, January 11, 2006 02:33:37 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
You probably don't really need to do this, as Heimdal comes with an afslog
that should work fine -- although, I don't know if it supports the -setpag
flag to set a PAG for the parent process. Unfortunat
zeroguy <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> wrote:
>> Soon we'll have the OpenAFS aklog packaged for Debian.
> Russ, just wondering, is there any specific time or a specific release
> you're planning on packaging it (like, maybe 1.4.1?)
1.4.1, yes.
> Will it remain a
Douglas E Engert <[EMAIL PROTECTED]> writes:
> Its actually knowing what the syscall is that AFS uses to set the PAG.
> and what to do if the syscall fails. You don't really have to link in
> any AFS library. The pam_afs2 does this, and uses no AFS or Kerberos
> libs.
> It would be nice AFS prov
Russ Allbery wrote:
Juha Jäykkä <[EMAIL PROTECTED]> writes:
You probably don't really need to do this, as Heimdal comes with an afslog
that should work fine -- although, I don't know if it supports the -setpag
flag to set a PAG for the parent process. Unfortunately, doing PAM
properly re
Juha Jäykkä <[EMAIL PROTECTED]> writes:
>> Ah, okay, I didn't realize that.
> It's the best working solution I have been able to come up with. Its
> being monolithic makes it non-ideal, but it seems to work fine. It even
> parses krb5.conf's [appdefaults] pam = { ... } and is easy to
> configure.
On Wed, 11 Jan 2006 00:45:38 -0800
Russ Allbery <[EMAIL PROTECTED]> wrote:
> Soon we'll have the OpenAFS aklog packaged for Debian.
Russ, just wondering, is there any specific time or a specific release
you're planning on packaging it (like, maybe 1.4.1?) Will it remain a
separate package?
Juha Jäykkä wrote:
sshd won't leak this token to the user if your PAM setup is appropriate.
You have to make sure that the user is put into their own PAG as part of
the session initialization process, even if they don't get a token.
I would have thought pam_krb5.so [1] does this by itself,
Juha Jäykkä <[EMAIL PROTECTED]> writes:
> I disagree. From its README:
> o tokens
> Create a new AFS PAG and obtain AFS tokens during the authentication
> phase. By default, tokens are obtained for the local cell (and the cell
> which contains the user's home directory, if they're not the sam
Juha Jäykkä <[EMAIL PROTECTED]> writes:
> I would have thought pam_krb5.so [1] does this by itself, but apparently
> I am mistaken (again).
It's only a PAM module for Kerberos. It doesn't know anything about AFS.
> While it would be relatively easy to write a small pam module to handle
> the cr
> sshd won't leak this token to the user if your PAM setup is appropriate.
> You have to make sure that the user is put into their own PAG as part of
> the session initialization process, even if they don't get a token.
I would have thought pam_krb5.so [1] does this by itself, but apparently I
am
Jeffrey Hutzelman wrote:
Support for directory
entries pointing to files in located in *other* volumes (and with what
type of ACL semantics)?
Huh? Why would we do that?
Directory entries describe files within a single directory.
Well, you're redesigning so this is the time to ask why al
Juha Jäykkä <[EMAIL PROTECTED]> writes:
> Seems to me, then, that PAM is lacking proper handling of user
> authorization. It may not be much different from handling authorization
> and authentication together, but looks like having different hooks for
> these different things might be a good idea.
On Monday, January 09, 2006 09:45:46 AM +0100 Rainer Toebbicke
<[EMAIL PROTECTED]> wrote:
Jeffrey Hutzelman wrote:
Getting a directory format that would be backward compatible with
existing clients was a tricky bit of work, but I think we succeeded.
At what state? Source code or "design
Jeffrey Hutzelman wrote:
Getting a directory format that would be backward compatible with
existing clients was a tricky bit of work, but I think we succeeded.
At what state? Source code or "design document"?
Support for directories with > 64k-odd entries? Support for directory
entries p
> Conceptually, yes.
> In the PAM world, authorization checks such as this are done as part of
> the "authenticate" operation, not the "account management" operation.
Seems to me, then, that PAM is lacking proper handling of user
authorization. It may not be much different from handling authoriza
On Friday, January 06, 2006 10:31:10 AM -0500 Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
At the same time the directory format is extended to support Unicode
we should also make changes to support multiple data streams per file
and a method of supporting additional file attributes.
Those a
On Friday, January 06, 2006 09:16:40 AM -0500 Jim Rees <[EMAIL PROTECTED]>
wrote:
authentication identities to AFS ID's), the AFS directory format (to
support unicode filenames and >64K files per directory),
Does the directory format have to change for unicode? I'm pretty sure it
will
Jim Rees <[EMAIL PROTECTED]> writes:
> Therefore, for a Unicode directory entry there must be two strings
> stored: the normalized string that is used for directory searches and
> a display string that is the string the user entered.
> Is there precedent for this? Do any other unicode bas
chas williams - CONTRACTOR wrote:
> In message <[EMAIL PROTECTED]>,Jeffrey Altman writes:
>> we should also make changes to support multiple data streams per file
>
> just curious. could you elaborate on this one a bit? are you talking
> about versioning, "resource forks", or something else?
Tr
Jim Rees wrote:
> Therefore, for a Unicode
> directory entry there must be two strings stored: the normalized string
> that is used for directory searches and a display string that is the
> string the user entered.
>
> Is there precedent for this? Do any other unicode based file systems
Therefore, for a Unicode
directory entry there must be two strings stored: the normalized string
that is used for directory searches and a display string that is the
string the user entered.
Is there precedent for this? Do any other unicode based file systems do it
this way?
In message <[EMAIL PROTECTED]>,Jeffrey Altman writes:
>we should also make changes to support multiple data streams per file
just curious. could you elaborate on this one a bit? are you talking
about versioning, "resource forks", or something else?
___
>This appears to be a security decision based primarily on a technical
>limitation in AFS.
Sure was; I never said otherwise. I fully admit it's not ideal, but I
have to work with the tools that I have, not the ones that I wish I
had. Certainly everybody makes those kinds of decisions every day.
Jim Rees wrote:
> authentication identities to AFS ID's), the AFS directory format (to
> support unicode filenames and >64K files per directory),
>
> Does the directory format have to change for unicode? I'm pretty sure it
> will hold utf-8 with no changes. Other things would have to change
authentication identities to AFS ID's), the AFS directory format (to
support unicode filenames and >64K files per directory),
Does the directory format have to change for unicode? I'm pretty sure it
will hold utf-8 with no changes. Other things would have to change of
course.
__
On Thursday, January 05, 2006 04:21:52 PM -0500 Rodney M Dyer
<[EMAIL PROTECTED]> wrote:
Wasn't there some talk about the DFS code being opened? And didn't DFS
have file level ACLs? Could any of that code be ported to AFS, or is
there already a project underway for file level ACLs in AFS?
At 03:30 PM 1/5/2006, Lester Barrows wrote:
On Thursday 05 January 2006 7:32 am, Ken Hornstein wrote:
This appears to be a security decision based primarily on a technical
limitation in AFS. The per-directory ACL limitation itself was more or less
what I was discussing, as it has caused me more t
I have found this discussion very interesting, and it appears many sites
are living with the "l" symlinks for .k5login to a directory with "rl".
mostly because that is the simplest thing to do.
But after reading Jeff Hutzelman's note from earlier today, maybe the
problem is not with AFS but with K
On Thursday 05 January 2006 7:32 am, Ken Hornstein wrote:
> Given the choice between files possibly being world-readable and users
> having to expose their password for every login (even if you're
> encrypting the session, we've learned the hard way that isn't enough
> anymore), we decided to go wi
>Most of our users will place files in their home directory, even in the top
>level, expecting them to be secure. Additionally, I fully expect that most
>users will leave permissions with the default settings. In this case, when a
>user creates a directory it inherits the ACL privileges of its p
On Thursday, January 05, 2006 01:05:19 AM +0100 Sergio Gelato
<[EMAIL PROTECTED]> wrote:
* Russ Allbery [2006-01-04 14:55:19 -0800]:
Sergio Gelato <[EMAIL PROTECTED]> writes:
> As far as the screensavers' not running the account stack, I'd be more
> worried about what happens when a Kerbero
On Wednesday, January 04, 2006 05:31:15 PM -0600 "Douglas E. Engert"
<[EMAIL PROTECTED]> wrote:
Exactly where in the PAM stack do you want
to obtain (and, if need be, discard) this extra token? pam_open_session()
I am not sure. It has to be after the GSSAPI or pam_authenticate has a TGT
(
* Russ Allbery [2006-01-04 14:55:19 -0800]:
> Sergio Gelato <[EMAIL PROTECTED]> writes:
> > As far as the screensavers' not running the account stack, I'd be more
> > worried about what happens when a Kerberos password has just expired
> > than about krb5_kuserok() being skipped: after all, the ini
Sergio Gelato wrote:
* Douglas E. Engert [2006-01-04 14:19:56 -0600]:
Russ Allbery wrote:
Douglas E Engert <[EMAIL PROTECTED]> writes:
The sshd could accept a forwarded ticket for the sole purpose of using
it to get an AFS token so the sshd could access the .k5login file before
the krb5
Jeffrey Hutzelman <[EMAIL PROTECTED]> writes:
> Russ Allbery <[EMAIL PROTECTED]> wrote:
>> The screen savers that I've looked at actually explicitly don't call
>> the account stack (or call it and ignore its return status) because
>> they don't want to lock out users with expired accounts.
>>
>>
On Wednesday, January 04, 2006 02:55:19 PM -0800 Russ Allbery
<[EMAIL PROTECTED]> wrote:
As far as the screensavers' not running the account stack, I'd be more
worried about what happens when a Kerberos password has just expired
than about krb5_kuserok() being skipped: after all, the initial
On Wednesday, January 04, 2006 04:30:37 PM -0500 Ken Hornstein
<[EMAIL PROTECTED]> wrote:
With AFS we have to decide whether to allow the world to read the entire
top level of a home directory, or to always require the username and
password for each login. At the moment I've chosen the lat
On Wednesday 04 January 2006 1:48 pm, Jeffrey Altman wrote:
> This should be a reasonable approach. For all machines that
> are being logged into using gssapi krb5, those machines must
> have been issued a Kerberos principal and they must have a
> keytab. Assign the principal an AFS ID and then
On Wednesday, January 04, 2006 03:02:20 PM -0500 Jeffrey Altman
<[EMAIL PROTECTED]> wrote:
Russ Allbery wrote:
Douglas E Engert <[EMAIL PROTECTED]> writes:
The client is, understandably, not going to forward the ticket until
after the authentication step is complete, so what this basically
Sergio Gelato <[EMAIL PROTECTED]> writes:
> This is straying off-topic, but I'd argue that the default behaviour of
> a PAM module should still be the correct one: call krb5_kuserok() from
> pam_sm_acct_mgmt() only. Then one can add options to work around bugs in
> important applications.
The pro
Lester Barrows <[EMAIL PROTECTED]> writes:
> On Wednesday 04 January 2006 1:36 pm, Russ Allbery wrote:
>> No, you only have to decide whether to allow the world to *list* the
>> entire top level of a home directory. Read is not required.
> That's still more privileges than we can give out based
On Wednesday 04 January 2006 1:36 pm, Russ Allbery wrote:
> No, you only have to decide whether to allow the world to *list* the
> entire top level of a home directory. Read is not required.
That's still more privileges than we can give out based on our security
policy, since this is the default
On Wednesday 04 January 2006 1:30 pm, Ken Hornstein wrote:
> FWIW, we choose the exact opposite option (world readable home directory)
> for the exact same reason (lack of confidence in the vigilance of users).
>
> --Ken
Most of our users will place files in their home directory, even in the top
* Douglas E. Engert [2006-01-04 14:19:56 -0600]:
> Russ Allbery wrote:
> >Douglas E Engert <[EMAIL PROTECTED]> writes:
> >
> >>The sshd could accept a forwarded ticket for the sole purpose of using
> >>it to get an AFS token so the sshd could access the .k5login file before
> >>the krb5_kuserok was
This should be a reasonable approach. For all machines that
are being logged into using gssapi krb5, those machines must
have been issued a Kerberos principal and they must have a
keytab. Assign the principal an AFS ID and then use a program
such as kstart to obtain and maintain a AFS token in t
Lester Barrows <[EMAIL PROTECTED]> writes:
> With AFS we have to decide whether to allow the world to read the entire
> top level of a home directory, or to always require the username and
> password for each login.
No, you only have to decide whether to allow the world to *list* the
entire top l
Jeffrey Altman <[EMAIL PROTECTED]> writes:
> Processing of the .k5login file is not an authentication operation, it
> is an authorization operation. Therefore, it is perfectly reasonable
> for the client to mutually authenticate with a server, forward a ticket
> and then have access rejected due
>With AFS we have to decide whether to allow the world to read the entire top
>level of a home directory, or to always require the username and password for
>each login. At the moment I've chosen the latter, since the former requires
>vigilance on the part of the user that I'm not comfortable wi
On Wednesday 04 January 2006 12:42 pm, Douglas E. Engert wrote:
> The problem is not about ACLs on files or directories, it more about
> allowing world readable access to what some might consider sensitive data.
> I still would not like the .k5login world readable.
>
> What I meant about NFS vs AFS
Jim Rees wrote:
Any distributed file system has the same problem, if files in the home
directory need to be accessed during login. NFSv4 may have to address the
same problems.
The problem with afs is that you can't put an acl on a file. NFSv4 doesn't
have this problem.
The problem is
Any distributed file system has the same problem, if files in the home
directory need to be accessed during login. NFSv4 may have to address the
same problems.
The problem with afs is that you can't put an acl on a file. NFSv4 doesn't
have this problem.
_
Russ Allbery wrote:
Douglas E Engert <[EMAIL PROTECTED]> writes:
The sshd could accept a forwarded ticket for the sole purpose of using
it to get an AFS token so the sshd could access the .k5login file before
the krb5_kuserok was called (There might be some other dot files that
could also b
Russ Allbery wrote:
> Douglas E Engert <[EMAIL PROTECTED]> writes:
> The client is, understandably, not going to forward the ticket until after
> the authentication step is complete, so what this basically means is
> authenticating the user, accepting the forwarded ticket, and then
> reauthenticati
Douglas E Engert <[EMAIL PROTECTED]> writes:
> The sshd could accept a forwarded ticket for the sole purpose of using
> it to get an AFS token so the sshd could access the .k5login file before
> the krb5_kuserok was called (There might be some other dot files that
> could also be accessed early.)
Russ Allbery wrote:
Juha Jäykkä <[EMAIL PROTECTED]> writes:
In my opinion, the problem is pam_krb5.so, which checks the .k5login
file in pam_sm_authenticate(). Its own documentation says it only checks
.k5login in pam_sm_acct_mgmt(), but this is incorrect. I am not sure
this is a bug, thoug
Juha Jäykkä <[EMAIL PROTECTED]> writes:
> In my opinion, the problem is pam_krb5.so, which checks the .k5login
> file in pam_sm_authenticate(). Its own documentation says it only checks
> .k5login in pam_sm_acct_mgmt(), but this is incorrect. I am not sure
> this is a bug, though, and therefore ha
> /afs/italia/project/bigbox/e3/i386/updates/openssh*
You don't happen to have the sources around? I can convert the binary rpms
to binary debs, but that will eventually lead to library incompatibilities
and such. What kind of modifications have you done to the ssh server?
In my opinion, the prob
Try this:
/afs/italia/project/bigbox/e3/i386/updates/openssh*
(You will have to install the right /etc/krb5.conf and /etc/krb5.keytab).
Andrei.
On 1/4/06, Juha Jäykkä <[EMAIL PROTECTED]> wrote:What is The Way to have all three (afs, heimdal and sshd) work together?
Hi!
We have a nicely working Heimdal + LDAP database (the OS is Debian/GNU
Linux), providing user authentication and authorization. Now, we would
like to move from somewhat unreliable NFS to something more robust - and
especially something more firewall friendly - and are considering OpenAFS.
Ther
89 matches
Mail list logo
