-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas E. Engert wrote:
> Can you run klist -e -t -K -k afstest-md5.keytab
> and verify that the key matches what asetkey has.
Thank you! This led to the solution... It did NOT match, as the key had
been added with bos addkey with the most recent s
Brandon S. Allbery KF8NH wrote:
On Jul 17, 2009, at 15:01 , Eric Chris Garrison wrote:
[r...@rufus2 etc]# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: afs/afstest.iu@ads.iu.edu
Valid starting ExpiresService principal
07/17/09 14:34:44 07/18/09 00:34:44 kr
"Brandon S. Allbery KF8NH" writes:
> On Jul 17, 2009, at 15:01 , Eric Chris Garrison wrote:
>> [r...@rufus2 etc]# klist -e
>> Ticket cache: FILE:/tmp/krb5cc_0
>> Default principal: afs/afstest.iu@ads.iu.edu
>>
>> Valid starting ExpiresService principal
>> 07/17/09 14:34:44 07
On Jul 17, 2009, at 15:01 , Eric Chris Garrison wrote:
[r...@rufus2 etc]# klist -e
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: afs/afstest.iu@ads.iu.edu
Valid starting ExpiresService principal
07/17/09 14:34:44 07/18/09 00:34:44 krbtgt/ads.iu@ads.iu.edu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Altman wrote:
> Eric Chris Garrison wrote:
>> Anything else that we might be missing? I keep thinking it must be
>> something simple.
>
> It has to be key related. An authenticated/encrypted connection is
> possible provided that the key wor
Eric Chris Garrison wrote:
> Anything else that we might be missing? I keep thinking it must be
> something simple.
It has to be key related. An authenticated/encrypted connection is
possible provided that the key works. Even if the user name is not
found in the protection database.
I would ve
Eric Chris Garrison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas E. Engert wrote:
And after you reset the desonly bit in AD, did you use ktpass with
-pass somepassword -out keytabfile
or did you use the -rndPass option?
The ADS admin says "We always use the rndPass option fo
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Douglas E. Engert wrote:
> And after you reset the desonly bit in AD, did you use ktpass with
> -pass somepassword -out keytabfile
> or did you use the -rndPass option?
The ADS admin says "We always use the rndPass option for generating the
keytabs. Y
Eric Chris Garrison wrote:
> Okay, we continue to fight this. We found that despite having an
> alternate realm name in /usr/afs/etc/krb.conf, users from that realm were
> being treated as unauthorized, anonymous users, rather than being mapped
> as they should be.
>
> We looked into enctypes as
Eric Chris Garrison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Okay, we continue to fight this. We found that despite having an
alternate realm name in /usr/afs/etc/krb.conf, users from that realm were
being treated as unauthorized, anonymous users, rather than being mapped
as they
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Russ Allbery wrote:
> Did you update KeyFile with the new service principal that you got from
> your ADS admin and make sure that the kvno in KeyFile matches the kvno in
> Active Directory?
Yes.
- --
Eric Chris Garrison | Principal Mass St
Eric Chris Garrison writes:
> So, we got a des-crc-md5 service principal from our ADS admin. Now the
> ticket decoding is failing in krb5_des_decrypt() in rxkad/ticket5.c on
> the server side.
>
> After aklog, this is what klist shows for afs/afstest.iu.edu:
> 07/16/09 14:43:22 07/17/09 00:43:1
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Okay, we continue to fight this. We found that despite having an
alternate realm name in /usr/afs/etc/krb.conf, users from that realm were
being treated as unauthorized, anonymous users, rather than being mapped
as they should be.
We looked into enct
Simon Wilkinson wrote:
On 9 Jul 2009, at 16:50, Douglas E. Engert wrote:
Depends on what data you put in AFS, and is the AFS network traffic
sniffable
You would need to do a risk assessment of you situation.
And when you do that risk assessment, consider the sentiments
expressed in:
http
On 9 Jul 2009, at 16:50, Douglas E. Engert wrote:
Depends on what data you put in AFS, and is the AFS network traffic
sniffable
You would need to do a risk assessment of you situation.
And when you do that risk assessment, consider the sentiments
expressed in:
http://xkcd.com/538/
S.
Eric Chris Garrison wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Altman wrote:
Garrison, Eric C wrote:
07/08/09 14:53:56 07/09/09 00:53:44 afs/afstest.iu@ads.iu.edu
renew until 07/09/09 14:53:40, Etype (skey, tkt): AES-256 CTS mode
with 96-bit
SHA-1 HMAC, AES-256
Eric Chris Garrison writes:
> Jeffrey Altman wrote:
>> The answer is right above. AES-256 is not DES-CBC-CRC
>
> I'm told by our ADS admin that DES3 isn't supported,
That wouldn't help; AFS doesn't support DES3 anyway.
> and DES-CBC-CRC is somewhat weak by modern standards. How concerned
> sh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Altman wrote:
> Garrison, Eric C wrote:
>
>> 07/08/09 14:53:56 07/09/09 00:53:44 afs/afstest.iu@ads.iu.edu
>> renew until 07/09/09 14:53:40, Etype (skey, tkt): AES-256 CTS mode
>> with 96-bit
>> SHA-1 HMAC, AES-256 CTS mode with 96
Garrison, Eric C wrote:
> 07/08/09 14:53:56 07/09/09 00:53:44 afs/afstest.iu@ads.iu.edu
> renew until 07/09/09 14:53:40, Etype (skey, tkt): AES-256 CTS mode
> with 96-bit
> SHA-1 HMAC, AES-256 CTS mode with 96-bit SHA-1 HMAC
>
> So what else should I look for in the token being bad in
Garrison, Eric C wrote:
Quoting Jeffrey Altman :
Eric Chris Garrison wrote:
...but as ecgar...@ads.iu.edu:
Wed Jul 1 15:58:37 2009 [6] EVENT AFS_Aud_Unauth CODE -1 STR
AFS_SRX_StData
Wed Jul 1 15:58:37 2009 [6] EVENT AFS_SRX_StData CODE 0 NAME --UnAuth--
HOST 149.166.144.33 ID 32766 FI
Quoting Jeffrey Altman :
Eric Chris Garrison wrote:
...but as ecgar...@ads.iu.edu:
Wed Jul 1 15:58:37 2009 [6] EVENT AFS_Aud_Unauth CODE -1 STR AFS_SRX_StData
Wed Jul 1 15:58:37 2009 [6] EVENT AFS_SRX_StData CODE 0 NAME --UnAuth--
HOST 149.166.144.33 ID 32766 FID 536870933:2:2
So the ADS.I
Eric Chris Garrison wrote:
> ...but as ecgar...@ads.iu.edu:
>
> Wed Jul 1 15:58:37 2009 [6] EVENT AFS_Aud_Unauth CODE -1 STR AFS_SRX_StData
> Wed Jul 1 15:58:37 2009 [6] EVENT AFS_SRX_StData CODE 0 NAME --UnAuth--
> HOST 149.166.144.33 ID 32766 FID 536870933:2:2
>
> So the ADS.IU.EDU user is s
>>> If the
>>> krb.conf file states
>>>
>>> ADS.IU.EDU AFSTEST.IU.EDU
>
> wait, they should be one per line. are they?
I reread the code. All on one line, space-separated, should be fine.
however, you need not relist the one that's in ThisCell.
Russ' point also matters. Is the ADS user's key a
Eric Chris Garrison writes:
> What I'm seeing now though, is that although used asetkey to add the
> service principal from the ADS realm to my test cell, permissions
> aren't working as I'd expect.
>
> So, we have realm AFSTEST.IU.EDU and ADS.IU.EDU. Both in the KeyFile and
> in the /usr/afs/et
On Wed, Jul 1, 2009 at 4:52 PM, Eric Chris Garrison wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Jeffrey Altman wrote:
>> Eric Chris Garrison wrote:
From: Andrew Deason
> I've added an afs service principal from each of two realms to the
> KeyFile using asetkey. I've
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jeffrey Altman wrote:
> Eric Chris Garrison wrote:
>>> From: Andrew Deason
I've added an afs service principal from each of two realms to the
KeyFile using asetkey. I've added both realms in /etc/krb.conf, the
first two lines of the f
Eric Chris Garrison wrote:
>> From: Andrew Deason
>>> I've added an afs service principal from each of two realms to the
>>> KeyFile using asetkey. I've added both realms in /etc/krb.conf, the
>>> first two lines of the file being the two realms.
>> You probably want /usr/afs/etc/krb.conf (if us
On Jul 1, 2009, at 12:17, Eric Chris Garrison
wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
From: Andrew Deason
I've added an afs service principal from each of two realms to the
KeyFile using asetkey. I've added both realms in /etc/krb.conf,
the
first two lines of the fil
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> From: Andrew Deason
> > I've added an afs service principal from each of two realms to the
> > KeyFile using asetkey. I've added both realms in /etc/krb.conf, the
> > first two lines of the file being the two realms.
>
> You probably want /usr/afs
29 matches
Mail list logo
