[32308] in Kerberos
Re: passwd, kpasswd
daemon@ATHENA.MIT.EDU (Matej Zagiba)
Wed May 5 14:09:56 2010
To: undisclosed-recipients:;undisclosed-recipients:;@MIT.EDU
Message-ID: <4BE1A425.2040104@fmph.uniba.sk>
Date: Wed, 05 May 2010 19:00:21 +0200
From: Matej Zagiba <matej.zagiba@fmph.uniba.sk>
MIME-Version: 1.0
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
In-Reply-To: <20100505081220.108010@gmx.net>
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
On 05/05/2010 10:12 AM, thom_schu@gmx.de wrote:> Hi,> Thanks for the answer.> Im not sure if I understood 100%.> Im talking only about user who have a kerberos-principal.> This user have only a kerberos-password and no "normal" account-password> anymore - is this right ? But then this user should only call kpasswd and> not passwd anymore (however I will turn off this). If it is like this, I> think, I understand.
Well, when passwords are stored in kerberos, then user can use kpasswd or passwd (if pam is set correctly)and results will be the same - changed password in kerberos database.
> But if these users will have still an "normal" account-password, then I> wouldnt understand - because I want to make all host more save using> kerberos, but let a second door open with "normal login".
May be little misunderstanding, I did not suggested two sets of passwords for users.
As kerberos is only authentication protocol, there is necessity to provide some user authorization database,either /etc/passwd, LDAP, NIS ...
Second door should be available only for selected users like admin or root - so only those users should have fullentry in /etc/passwd and /etc/shadow, other users do not need /etc/shadow entry at all, and their password in /etc/passwd can be safely set to "*" (this is only for testing anyway, keeping passwd file up to date on multiplehosts for multiple users will be nightmare). When using LDAP, no userPassword attribute should be set, better yet, changing that attribute by users should be forbidden (so LDAP is used for authorization and not authentication).
For advanced configurations it is entirely valid to store another passwords in this databases too,but in general it's not a good idea to use them as alternative to kerberos (second doors). First of all, these passwords tends to loose sync for various reasons (like using kpasswd instead of passwd, incorectly configured hosts, changing password in LDAP via webmail interface and so on). Then, it is confusing for users, when to use which password, and it complicates user support. And last but not least, it can weaken the security.
Matej
> Thanks>> gizmo>>> hi,>>>> usually you don't want those to be in sync. When user changes password>> on one>> machine (and kerberos) change is not propagated to other machines, so>> thigs break.>> And there is always problem with kpasswd, changes with kpasswd will not be>> propagated at all.>>>> My approach is to have two sets of accounts - 'local' with password in>> /etc/shadow>> and 'global' with kerberos authentication. I use LDAP to propagate global>> accounts and I do not use LDAP authentication, no password is stored in>> LDAP.>> you can even have third set of accounts - "LDAP" accounts which>> authenticate against LDAP>> and do not have any kerberos principal associated. And for testing, try>> account with>> * instead of password in /etc/passwd.>>>> So You can try something like this:>>>> password requisite pam_pwcheck.so nullok cracklib>> password sufficient pam_unix2.so nullokuse_authtok>> password sufficient pam_krb5.so nullok use_authtok>> password required pam_deny.so>>>>>> Matej>>>> --> GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT!> Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01> ________________________________________________> Kerberos mailing list Kerberos@mit.edu> https://mailman.mit.edu/mailman/listinfo/kerberos
________________________________________________Kerberos mailing list Kerberos@mit.eduhttps://mailman.mit.edu/mailman/listinfo/kerberos
