Franco "Sensei" wrote:
That's my point. Is anyone thinking about avoiding all the non-necessary infrastructures like AD. Using local accounts is crazy, you have to manage directly each client and that's not good or even feasable.
The integrated login of afs with k5 should probably be extended with a unix like approach to remote profiles, without managing other servers. AD adds another layer.
Is worth it? I mean, I'd like to see something like that, I don't know if the afs administrators would be happy having this facility. I really do think so, since it would avoid many other implications (x-trust, ad's ldap, ad's accounts, passwords in both worlds...).
You do not seem to understand how integrated login works. You login to Windows and Windows finds the account. The account indicates where the profile is located including the User's Registry Hive. Windows calls the network provider to enable the provider to obtain credentials to access network services in case they are required to load the profile. Windows then loads the profile.
There is no interaction by anything provided by MIT KFW or OpenAFS which can determine what the account is and where its profile is located. Now you can map a Kerberos 5 principal to a local account via the registry and you can point the profile for that account to AFS, but you can't use a non-Windows Kerberos 5 principal to define a new account.
Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
