[OpenAFS] The removal of afscreds.exe and afs_config.exe on Windows
Vista and Windows 7: Seeking Opinions
Thu, 01 Oct 2009 01:14:32 +0200
This is a cryptographically signed message in MIME format.
Content-Type: text/plain; charset=UTF-8
Dave B wrote:
> A good discussion happening here...
> On Wed, Sep 30, 2009 at 11:11:41PM +0200, Jeffrey Altman wrote:
>> 1. afscreds simply doesn't work reliably. as a result, its continued
>> use is in my opinion not an option on Vista, 2008 and Windows 7.
> Fortunately, we use it very simply, and at the moment, mainly on XP and on
> Server 2003 (there are < 5 vista machines using it, and of those, the folk
> dont' really use afs). Since it will still be an optional install in XP, that
> keeps us happy for the moment. We will probably be going to Windows 7,
> assuming that Windows 7 doesn't break things worse than XP in early 2010.
As I have mentioned on other threads and in the announcement for 1.5.64,
currently Windows 7 has a serious bug that will prevent the SMB
Redirector from being able to resolve \\AFS if the network IP assignment
changes after boot. If you are planning on moving to Windows 7, please
test OpenAFS on Win7 and file the appropriate bug reports with
Microsoft. Only by having lots of orgs reporting the bug will it be
given high enough priority to have the fix pushed by Windows Update.
>> 2. it is true that Network Identity Manager cannot assume that it
>> should obtain an afs token automatically for the default workstation
>> cell in the case where the realm name and cell name do not match.
>> However, the fact that realm FOO.EXAMPLE.COM should be used for
>> cell bar.example.com can be specified in the registry as part of
>> your transformed OpenAFS installer or pushed via group policy in
>> managed environments.
> That would be a good thing. Need to spend some time with the docs and test
> this registry value. I seem to recall that even with the afs provider
> installed, the obtain afs tokens bit was also turned off by default (perhaps
> an installtion of order thing). But, my memory is fuzzy since it's been a
> while, and maybe, once again, there's a registry setting that sets this.
The "disable afs provider" option is not enabled by default.
>> afscreds requires that the user provide three values:
>> a. cellname
>> b. user@REALM
>> c. password
>> in order to make the cross-realm case work.
> for those users that need to login, value a is automagically filled in with
> the registry name. That's good. valule b may automagically fill in with the
> last thing they used, I don't recall. If not, users know to use the user@REALM
> format. And, of course, they darn well better know value c :)
The logic by which 'b' is populated is quite complicated. It depends on
whether the windows logon is a domain logon or not; whether integrated
logon is in use; whether the user currently has tokens; and whether
there is a TGT for a realm that matches the cell name at the time
afscreds was started.
'c' of course depends on there being a password. afscreds.exe cannot
work at all in a world with non-password based Kerberos authentication.
>> In early versions of the AFS provider, tokens for the workstation
>> cell were obtained for any Kerberos identity that was used for
>> logon. This caused serious support headaches for sites that use
>> Network Identity Manager with multiple identities in realms.
>> In the case where two active identities could both obtain a token
>> for the default workstation cell the token that was in use at any
>> given time would be random.
> as long as this doesn't make it more complicated for sites only dealing with a
> single kerberos identity.
As Chaz pointed out, even if you only have single realm and cell
you can still have cases where there are users at the site with
multiple Kerberos identities.
>> 3. Network Identity Manager's Kerberos v5 support permits the user
>> to specify their own values for lifetime, renew-lifetime, forwarding,
>> etc. This is the same behavior as all previous Kerberos ticket
>> managers such as krb5 and leash32. I have never seen a request
>> filed with MIT or Secure Endpoints to suppress this ability. It
>> is certainly something that could easily be added as a local machine
>> option that could be added to the KFW installer via a transform or
>> pushed via global policy.
> Will have to put filing such a request on my TODO list. If someone even says
> "oh what's this" and moneksy with the sliders, they've just broken my system
> defaults. In some scenarios that is a good thing. Not in our case.
>From the Network Identity Manager perspective I have already added it
to the wish list. From the MIT perspective, I have no idea if they are
ever going to release another KFW for end users. That is part of the
reason why Secure Endpoints is porting Heimdal to Windows.
>> I hope my comments have addressed your concerns. If they haven't
>> then we need to discuss how the creation of another replacement
>> for afscreds.exe should be pursued. The design of the existing
>> tool is flawed and cannot be distributed for use with modern versions
>> of Windows.
> I think with a couple of simple changes/hacks/settings/etc, network identity
> manager can be made to work well.
I agree. I think those changes are in version 2.
Content-Type: application/x-pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature