her then one. If the user does this
3 times, its 6 strikes, and this may be enough to turn off the card.
I suggest don't try and use a password for a PIN. When PIN pad readers
are in wide use, you could not use the password anyway, as the PIN reader
is designed to send the PIN directly to the
Darren J Moffat wrote:
> Douglas E. Engert wrote:
>>> I really strongly dislike the idea of having a special password that
>>> causes
>>> it to behave differently. It just smells like a bad hack.
>>
>> Yes, it is a hack, based on the current pam lim
Will Fiveash wrote:
> On Tue, Nov 10, 2009 at 08:54:52AM -0600, Douglas E. Engert wrote:
>>
>> Will Fiveash wrote:
>>> On Mon, Nov 09, 2009 at 02:20:45PM -0800, Gary Winiger wrote:
>>>>>>> I want to see an updated pam_krb5(5) man page explaining
differently. It just smells like a bad hack.
Yes, it is a hack, based on the current pam limitations of only prompting
for user and password. A more flexible pam architecture could prompt for type
of authentication the user wants to try.
>
> -Wyllys
>
>
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
d in, and can use other tools to change the password.
>
> If so then pam_krb5 needs to be stacked under pam_authtok_get since
> pam_krb5 above pam_authtok_get is only prompting for their PIN and does
> not prompt for their krb password and thus does not set PAM_AUTHTOK.
>
>> To me, a separate module as described seem cleaner and easier to understand
>> and configure than how I understand the current proposal.
>> What have I missed in my understanding (or have I missed so much that
>> it can't even be explained ;-)?
>
> I think my proposal is very similar functionally and requires less code
> change.
>
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
ance of pam_krb5 will try
> password based preauth and return success or failure.
But won't pam_authtok_get still prompt the user for a password?
If the pkinit works, this looks a lot like example 4.
>
>dtlogin auth required pam_unix_cred.so.1
>dtlogin auth required pam_krb5.so.1 passwd_fallback
>dtlogin auth requisite pam_authtok_get.so.1
>dtlogin auth required pam_krb5.so.1
Should the above be sufficient?
>dtlogin auth required pam_dhkeys.so.1
>dtlogin auth required pam_unix_auth.so.1
>
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
y, IMO there should be a way to select tokens for
> C_Login() in a way that takes PAM context (e.g., PAM_TTY) into
> consideration, so that only tokens that could be associated with a seat
> are used.
Yes that is an issue on other OSes too.
> But we don't need that urgently because for SunRay the seat
> is already taken into account via other methods, and for VTs we don't
> care very much about this.
>
> Nico
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
er
method is available to tell the differenrce between a smartcard and some
other crypto device supported below pkcs#11.
>
>>> I want to see an updated pam_krb5(5) man page explaining how to use PKINIT
>>> and including the example PAM stacks for use of PKINIT.
>> See Russ's pam_krb5.5 man page.
>
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
login.
So an pam_authtok prompt could be something like:
"Insert smartcard then enter user and enter null password"
>
> I want to see an updated pam_krb5(5) man page explaining how to use
> PKINIT and including the example PAM stacks for use of PKINIT.
See Russ's pam_krb5.5 man page.
>
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
paint myself in the corner on an implementation detail
>>> that I discover later on is not the most efficient/reasonable design :)
>>>
>>
>> I believe this case is incomplete as it stands. Were I an ARC member
>> I'd ask you to address these issues and update the materials, else
>> derail. I hope an ARC member does as much.
>>
>
> I certainly think that the session id SPI is a much needed project,
> however I don't think that it should be lumped into the CCAPI project.
> I can't decide on my own that CCAPI would block on a session id project,
> but I will certainly argue on both sides.
>
> Shawn.
> --
>
>
>
>
> ___
> kerberos-discuss mailing list
> kerberos-discuss at opensolaris.org
> http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss
--
Douglas E. Engert
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
10 matches
Mail list logo
