Personal Contacts

[jch]

The "user_unknown=ignore" line is irrelevant there because the effect of "sufficient" is to ignore a failing result.

If you have

Code: Select all

auth sufficient om_krb5
auth sufficient om_auth use_first_pass
auth required pam_deny
account required om_auth

(The password line is only used for password changes so I've missed that out) then the effect is that a user can log in with either his Kerberos password or his Scalix password. That may be what you want, but it has bad effects if you have wrong-password locking in your Kerberos server: SWA (for example) logs in several times and if you're logging in with your scalix password you'll lock your Kerberos account and that probably isn't what you intended.

That's good. What I've just said is what I also wrote in the om_krb5 man page. There's a lot of discussion about how it works in there.

Personally, I would always go for

Code: Select all

auth required om_krb5 user_unknown=ignore
auth optional om_auth nullok use_first_pass
account required om_auth
password required om_krb5 user_unknown=ignore
password optional om_auth

In this case a user known to Kerberos will always have to authenticate with Kerberos and a user not known to Kerberos will be able to use their Scalix password.

I've just put this in my ~/sys/pam.d/pamcheck file:

Code: Select all

auth required om_debug file=stderr verbosity=3
auth required om_krb5 user_unknown=ignore
auth optional om_auth nullok use_first_pass
account required om_auth
password required om_debug file=stderr verbosity=3
password required om_krb5 user_unknown=ignore
password optional om_auth

and now:

Code: Select all

$ sxpamauth -vvv haxby
pam_start_om("pamcheck", "haxby")
pam_authenticate()
om_debug: authenticate: PAM_USER = "HaxbyJohnsheepJohn Haxby"
om_debug: authenticate: PAM_AUTHTOK not set
om_krb5 (authenticate):
    user_unknown="Please ignore underlying account module"
    service="scalix_ual"
om_krb5: authid = "jch@UK.SCALIX.COM"
Kerberos Password:
om_krb5: service principal: "scalix-ual/sheep.uk.scalix.com"
om_krb5: authentication successful, set PAM_AUTHTOK
om_krb5: Success
om_auth: authenticate:
    nullok: yes
om_auth: use existing password
om_auth: save non-empty password in PAM_AUTHTOK
om_auth: bad password count now 1
om_auth: Authentication failure
pam_acct_mgmt()
om_auth: acct_mgmt
    max_age=-1
    exclude=<default>
    nocheck=<default>
    expiry
om_auth: Success

Authenticated

This isn't quite what you'll see (apart from having a different name and realm ) because it's my Scalix 11 development system. The bad password count is the thing that strikes me as most different. Anyway, if I now change my authid so that I'm not associated with a Kerberos acocunt:

Code: Select all

$ ommodu -o haxby --authid xyzzy
$ sxpamauth -vvv haxby
pam_start_om("pamcheck", "haxby")
pam_authenticate()
om_debug: authenticate: PAM_USER = "HaxbyJohnsheepJohn Haxby"
om_debug: authenticate: PAM_AUTHTOK not set
om_krb5 (authenticate):
    user_unknown="Please ignore underlying account module"
    service="scalix_ual"
om_krb5: authid = "xyzzy"
Kerberos Password:
om_krb5: service principal: "scalix-ual/sheep.uk.scalix.com"
om_krb5: authentication failed: Client not found in Kerberos database
om_krb5: Please ignore underlying account module
om_auth: authenticate:
    nullok: yes
Scalix password:
om_auth: save non-empty password in PAM_AUTHTOK
om_auth: reset bad password count
om_auth: Success
pam_acct_mgmt()
om_auth: acct_mgmt
    max_age=-1
    exclude=<default>
    nocheck=<default>
    expiry
om_auth: Success

Authenticated

There is a small difference in the way the sxpamauth handles passwords with the way that Scalix authentication handles passwords and I suppose I ought to deal with that at some stage), but I typed in my scalix password ("pass") twice to get this -- hitting CR causes different problems, but hey, this is a diagnostic tool it's supposed to have interesting features

Again, there are some differences in what you'll see to what's there (the reset bad password count for one), but it's essentially the same. The important thing to note is that there's no "xyzzy" in the Kerberos database so you can see that Kerberos reports that and then the om_krb5 module asked to be ignored.

You can play with the password changing yourself -- but be careful if you're using AD, it's sometimes set up to stop you changing your password too often or changing it back to what it was originally.

As I said, a lot of this is in the om_krb5 and om_debug man pages -- the only thing that's not is the error caused by having an empty password which is what I think you were having trouble with earlier. I've updated bug 13258 to include that though.

jch