Thanks Buck.Well that goes over my top.my requirement was simple to get the username (onlY) from the REMOTE_USER variable, if I had to do it in my script , that would become an per application task, my all scripts/programs look for or expect only the username in the REMOTE_USER, for that matter I do not want to have any side modifications. So if is at Kerberos level, that would make an per-host config and not the per-application config.
Regards. On 9/27/05, Buck Huppmann <[EMAIL PROTECTED]> wrote: > > On Tue, Sep 27, 2005 at 12:57:03PM +0000, Jeffrey Altman wrote: > > > > My problem is nothing except that to make modifications to REMOTE_USER > > > variable in the kerberos itself. > > > I mean when I am visiting a kerberos enabled webpage, after succesful > > > authentication the REMOTE_USER variable is being set as > > > "<user>@<mydomainname>" > > > I guess here the <domainname>, obviously it takes from domain_realm, > > > set in the /etc/krb5.conf page. > > > So, I want to make changes something that could make REMOTE_USER > > > variable just the "user" and not the "<user>@<mydomainname>". > > > > > > Response would be much appreciated. > > > > > > Regards, > > > Nikhil > > > > > > > You could make a change to do so but it would be unwise. What you > > refer to as <mydomainname> is really <REALM-OF-USER>. Since Kerberos > > supports authentication from multiple realms, it is necessary to > > include the full principal name in REMOTE_USER to distinguish the > > source of the authentication. > > if, however, you are willing to live with the defaults or have care- > fully crafted auth_to_local information in your krb5.conf, you can call > krb5_auth_to_localname() and then do a krb5_kuserok() check, to map > principal to local name, assuming there are ``local accounts'' on the > server, no?. this is the essence of how kerberized logins to shell, > ftp, et al. accounts are performed for most other services, i gather, > anyway, so i submitted a patch, via the modauthkerb sourceforge site, > to optionally do this, but it molders, so i'm probably wrong. (we are > using this functionality to make authorization decisions based on > account group memberships using mod_auth_pam's auth_sys_group_module, > in case you're wondering why the heck i bothered. it would be going a > step beyond the goofiness already indicated to use this kerberized > authentication and local-user mapping to have the request handler fork > a suexec-ish delegate, i am at least still fretting to myself) > -- Nikhil Google is Great ! ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
