pam-krb5 2.6 released

Douglas E. Engert deengert at anl.gov
Thu Dec 14 15:37:28 EST 2006



Markus Moeller wrote:

> "Douglas E. Engert" <deengert at anl.gov> wrote in message 
> news:4581A7BB.4090202 at anl.gov...
> 
>>
>>Markus Moeller wrote:
>>
>>
>>>Russ,
>>>
>>>I have a setup where I have two domains with trust and would like to have
>>>users from either domain to login to my Unix machine to applications 
>>>which
>>>can't use GSSAPI so I need to use pam_krb5 to have some form of SSO. My 
>>>Unix
>>>system is in DOMAIN1.COM which is configured to be the default domain in
>>>krb5.conf . I configured pam (on Solaris 2.8) as follows:
>>>
>>>#authentication
>>>other auth sufficient      pam_krb5-2.6.so.1 minimum_uid=100 debug
>>>other auth sufficient      pam_krb5-2.6.so.1 minimum_uid=100
>>>realm=DOMAIN2.COM use_first_pass debug
>>
>>Can you actually call this twice? Some version of pam_krb5 would
>>call pam_set_data(...."ctx"...) and overlay (or use) the pam_krb5
>>context set by the first one. (Don't know about 2.6.)
>>You could add a ctx_name option, so multiple invocations would
>>use different ctx's.
>>
> 
> 
> I guess that something like that is happening, but I don't think there is a 
> need to handle this via an additional option, the module should be able to 
> create a new krb5_context with DOMAIN2.COM e.g. after checking that the new 
> realm doesn't match the one retrieved by pam_get_data.

So in other words, use the realm as part of the name passed to
pam_set_data, or keep multiple copies of the data based on realm.
The realm name would then need to be supplied on the auth, account and session
entries too, so each could find the correct context.

Also using your method of trying the user and password against each realm
to see if there is a principal with that password in the first realm,
will cause overhead, log entries, and worse yet, if there is a
a matching user in the first realm realms belong to someone else, using
the wrong password may cause that principal to be locked out. It will look
like a sort of a DOS attack.

> 
> Markus
> 
> 
>>>other auth required       pam_unix.so.1 try_first_pass debug
>>># account
>>>other account sufficient   pam_krb5-2.6.so.1 minimum_uid=100 debug
>>>other account sufficient   pam_krb5-2.6.so.1 minimum_uid=100
>>>realm=DOMAIN2.COM debug
>>>other account required    pam_unix.so.1 debug
>>># session
>>>other session required     pam_default.so.1 debug
>>>
>>>The problem I have is that despite setting the realm to DOMAIN2.COM the
>>>system always tries to connect to kdcs of DOMAIN1.COM never DOMAIN2.COM
>>>despite getting an unknown user from DOMAIN1 for users of DOMAIN2 as it
>>>should be. It seems that the kerberos context of the first
>>>pam_sm_authenticate call is still used for the second despite changing 
>>>the
>>>realm.
>>>
>>>Thanks
>>>Markus
>>>
>>>BTW  Is it intention to use different defines for the below ?
>>>
>>># grep KRB5_GET_INIT *.[ch]
>>>config.h:/* #undef HAVE_KRB5_GET_INIT_OPT_SET_DEFAULT_FLAGS */
>>>support.c:#ifdef HAVE_KRB5_GET_INIT_CREDS_OPT_SET_DEFAULT_FLAGS
>>>#
>>>
>>>
>>>"Russ Allbery" <rra at stanford.edu> wrote in message
>>>news:871wnnyy8j.fsf at windlord.stanford.edu...
>>>
>>>
>>>>I'm pleased to announce release 2.6 of my Kerberos v5 PAM module.  This 
>>>>is
>>>>a bug-fix release; the feature improvements that were intended to be in
>>>>this release have been deferred to the next release.
>>>>
>>>>pam-krb5 is a Kerberos v5 PAM module for either MIT Kerberos or Heimdal.
>>>>It supports ticket refreshing by screen savers, configurable 
>>>>authorization
>>>>handling, authentication of non-local accounts for network services,
>>>>password changing, and password expiration, as well as all the standard
>>>>expected PAM features.  It works correctly with OpenSSH, even with
>>>>ChallengeResponseAuthentication and PrivilegeSeparation enabled, and
>>>>supports configuration either by PAM options or in krb5.conf or both.
>>>>
>>>>Changes from previous release:
>>>>
>>>>  Don't assume the pointer set by pam_get_user is usable over the life
>>>>  of the PAM module; instead, save a local copy.
>>>>
>>>>  Avoid a use of already freed memory when debugging is enabled.
>>>>
>>>>  Use __func__ instead of __FUNCTION__ and provide a fallback for older
>>>>  versions of gcc and for systems that support neither.  Should fix
>>>>  compilation issues with Sun's C compiler.
>>>>
>>>>  On platforms where we know the appropriate compiler flags, try to
>>>>  build the module so that symbols are resolved within the module in
>>>>  preference to any externally available symbols.  Also add the
>>>>  hopefully correct compiler flags for Sun's C compiler.
>>>>
>>>>You can download it from:
>>>>
>>>>  <http://www.eyrie.org/~eagle/software/pam-krb5/>
>>>>
>>>>Debian packages will be uploaded to Debian unstable once I have approval
>>>
>>>>from the release managers.
>>>
>>>>Please let me know of any problems or feature requests not already listed
>>>>in the TODO file.
>>>>
>>>>-- 
>>>>Russ Allbery (rra at stanford.edu) 
>>>><http://www.eyrie.org/~eagle/>
>>>
>>>
>>>
>>>
>>>
>>>________________________________________________
>>>Kerberos mailing list           Kerberos at mit.edu
>>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>>
>>>
>>
>>-- 
>>
>> Douglas E. Engert  <DEEngert at anl.gov>
>> Argonne National Laboratory
>> 9700 South Cass Avenue
>> Argonne, Illinois  60439
>> (630) 252-5444
>>________________________________________________
>>Kerberos mailing list           Kerberos at mit.edu
>>https://mailman.mit.edu/mailman/listinfo/kerberos
>>
> 
> 
> 
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444



More information about the Kerberos mailing list