Secure Endpoints has pushed fixes to https://github.com/heimdal/heimdal
for both the 'master' (aka pre-1.6) and 'heimdal-1-5-branch' branches.
Warning: Real-life results show that the code path for preauth always
seems to go through the strongest enctype configured (for example
aes256), even
Hi everyone,
After all of the cell's AFS servers are upgraded to 1.6.5 and DES is disabled,
will pre-1.6.5 clients still retain anonymous AFS access via system:anyuser
access and IP ACLs? I understand that authenticated access will not be
possible, but I want to clarify the anonymous access
anonymous access is unaffected.
However, a user with a token that is no longer accepted is not anonymous
On 7/30/2013 9:01 AM, Edgecombe, Jason wrote:
Hi everyone,
After all of the cell's AFS servers are upgraded to 1.6.5 and DES is
disabled, will pre-1.6.5 clients still retain anonymous
On 7/30/2013 6:57 AM, Harald Barth wrote:
Secure Endpoints has pushed fixes to https://github.com/heimdal/heimdal
for both the 'master' (aka pre-1.6) and 'heimdal-1-5-branch' branches.
Warning: Real-life results show that the code path for preauth always
seems to go through the strongest
Hi folks,
Could someone please remind me how to remove stuff from the /afs
directory? I recently discovered an empty directory there, called:
/afs/.:mount
Obviously it was created there by accident, probably by me. However,
when I try to remove it I get:
rmdir: failed to remove
On Tue, 30 Jul 2013, Jaap Winius wrote:
Hi folks,
Could someone please remind me how to remove stuff from the /afs directory? I
recently discovered an empty directory there, called:
/afs/.:mount
Obviously it was created there by accident, probably by me. However, when I
try to remove it I
On 7/30/13 12:01, Jaap Winius jwin...@umrk.nl wrote:
Hi folks,
Could someone please remind me how to remove stuff from the /afs
directory? I recently discovered an empty directory there, called:
/afs/.:mount
If you're using dynroot, that's an autocreated directory which can be used
to
On Tue, 30 Jul 2013 18:01:54 +0200
Jaap Winius jwin...@umrk.nl wrote:
Could someone please remind me how to remove stuff from the /afs
directory? I recently discovered an empty directory there, called:
/afs/.:mount
Obviously it was created there by accident, probably by me. However,
Quoting Benjamin Kaduk ka...@mit.edu:
I assume that you are not using dynroot?
Actually, I am using it. In /etc/openafs/afs.conf.client I have:
AFS_DYNROOT=true
The standard way to do such things is to make an additional mount of
the root.afs volume somewhere else in the local cell, and
Quoting Brandon Allbery ballb...@sinenomine.net:
If you're using dynroot, that's an autocreated directory which can be used
to access any volume directly: try /afs/.:mount/local.cell:root.cell
(replacing local.cell with the name of the local cell).
Well, whaddya know: it's not a mistake, it's
On Jul 30, 2013, at 19:09 , Jaap Winius wrote:
Quoting Benjamin Kaduk ka...@mit.edu:
I assume that you are not using dynroot?
Actually, I am using it. In /etc/openafs/afs.conf.client I have:
AFS_DYNROOT=true
The standard way to do such things is to make an additional mount of the
On Tue, 30 Jul 2013 11:25:05 -0500
Andrew Deason adea...@sinenomine.net wrote:
On Tue, 30 Jul 2013 18:01:54 +0200
Jaap Winius jwin...@umrk.nl wrote:
Could someone please remind me how to remove stuff from the /afs
directory? I recently discovered an empty directory there, called:
Where is the session key for the afs/cell@REALM service principal
derived from? If I remove the des-cbc-crc encryption type from both the
afs/cell@REALM and the user principals will things still work without
having to upgrade all clients to openafs 1.6.5?
I would like to get rid of the single des
On 7/30/13 14:39, John Sopko so...@cs.unc.edu wrote:
Where is the session key for the afs/cell@REALM service principal
derived from? If I remove the des-cbc-crc encryption type from both the
afs/cell@REALM and the user principals will things still work without
having to upgrade all clients to
On Tue, 30 Jul 2013 14:39:56 -0400
John Sopko so...@cs.unc.edu wrote:
Where is the session key for the afs/cell@REALM service principal
derived from?
Session keys aren't usually derived from anything in the principal;
they're chosen randomly. There is a situation for OpenAFS specifically
where
On Tue, 30 Jul 2013, Jeffrey Altman wrote:
This is an incorrect description. The explicit problem occurs when the
following combination is true:
1. user has one or more strong enctype keys with non-default
password salts
2. the only keys with default password salts are weak enctypes
3.
On 7/30/2013 7:32 PM, Benjamin Kaduk wrote:
On Tue, 30 Jul 2013, Jeffrey Altman wrote:
This is an incorrect description. The explicit problem occurs when the
following combination is true:
1. user has one or more strong enctype keys with non-default
password salts
2. the only keys
Andrew is spot-on, just two minor clarifications (inline)
On Tue, 30 Jul 2013, Andrew Deason wrote:
On Tue, 30 Jul 2013 14:39:56 -0400
John Sopko so...@cs.unc.edu wrote:
Where is the session key for the afs/cell@REALM service principal
derived from?
Session keys aren't usually derived from
On Tue, 2013-07-30 at 19:44 -0400, Jeffrey Altman wrote:
On 7/30/2013 7:32 PM, Benjamin Kaduk wrote:
On Tue, 30 Jul 2013, Jeffrey Altman wrote:
This is an incorrect description. The explicit problem occurs when the
following combination is true:
1. user has one or more strong
This is an incorrect description.
That might very well be, but I thought it was better than nothing
because others who are in trouble might want to know that they are not
alone ;-/
The explicit problem occurs when the
following combination is true:
1. user has one or more strong enctype
20 matches
Mail list logo
