"Douglas E. Engert" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > > Markus Moeller wrote: > >> "Douglas E. Engert" <[EMAIL PROTECTED]> wrote in message >> news:[EMAIL PROTECTED] >> >>> >>>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. >
I know of these issues. DOMAIN2.COM is a small domain and I know the IDs are not overlapping, why I thought when I saw the realm options that a simple pam.conf change could do it. I also like to use with a well supported module without patching it myself. Markus >> >> 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" <[EMAIL PROTECTED]> wrote in message >>>>news:[EMAIL PROTECTED] >>>> >>>> >>>>>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 ([EMAIL PROTECTED]) >>>>><http://www.eyrie.org/~eagle/> >>>> >>>> >>>> >>>> >>>> >>>>________________________________________________ >>>>Kerberos mailing list Kerberos@mit.edu >>>>https://mailman.mit.edu/mailman/listinfo/kerberos >>>> >>>> >>> >>>-- >>> >>> Douglas E. Engert <[EMAIL PROTECTED]> >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>>________________________________________________ >>>Kerberos mailing list Kerberos@mit.edu >>>https://mailman.mit.edu/mailman/listinfo/kerberos >>> >> >> >> >> >> ________________________________________________ >> Kerberos mailing list Kerberos@mit.edu >> https://mailman.mit.edu/mailman/listinfo/kerberos >> >> > > -- > > Douglas E. Engert <[EMAIL PROTECTED]> > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > ________________________________________________ Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos