On Wed, Jun 27, 2007 at 01:30:35PM -0700, Peter Eriksson wrote: > I'm investigating how to set up a really transparent trust between > two realms (1: Unix/Solaris - "IFM.LIU.SE", and 2: Microsoft AD: > "AD.IFM.LIU.SE" so that PC users authenticated to the AD system > can access services handled by the Solaris realm (for example being > able to access the mail system (SMTP AUTH and IMAP) and other stuff... > > Anyway, while doing that I'm currently looking at how to configure our > Solaris servers /etc/krb5.conf so that the users in the AD.IFM.LIU.SE > realm can be mapped to their right unix userid's (the login names are > identical). I *think* the answer to that is the auth_to_local stuff, but > the documation is really vague on how to _use_ it. And also, on Solaris 10 > update 3 the man page for krb5.conf only talks about auth_to_local_realm, > whereas some guides I've found on the net talks about auth_to_local. A > "strings" on the mech_krb5.so file seems to indicate though that both exists > (and a third auth_to_local_names). > > Does *anyone* actually know how these are used?
Here's what the Mapping GSS Credentials to UNIX Credentials section of the System Administration Guide: Security Services <http://docs.sun.com/app/docs/doc/816-4557/6maosrjkl?q=Mapping+GSS+Credentials+to+UNIX+Credentials&a=view> says: The Kerberos service provides a default mapping of GSS credential names to UNIX user IDs (UIDs) for GSS applications that require this mapping, such as NFS. GSS credential names are equivalent to Kerberos principal names when using the Kerberos service. The default mapping algorithm is to take a one component Kerberos principal name and use that component, which is the primary name of the principal, to look up the UID. The look up occurs in the default realm or any realm that is allowed by using the auth_to_local_realm ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ parameter in /etc/krb5/krb5.conf. For example, the user principal name bob at EXAMPLE.COM is mapped to the UID of the UNIX user named bob using the password table. The user principal name bob/admin at EXAMPLE.COM would not be mapped, because the principal name includes an instance component of admin. If the default mappings for the user credentials are sufficient, the GSS credential table does not need to be populated. In past releases, populating the GSS credential table was required to get the NFS service to work. If the default mapping is not sufficient, for example if you want to map a principal name which contains an instance component, then other methods should be used. There is a update to the man krb5.conf man page that will help (not sure when that will be out officially). I'll quote it here: auth_to_local_realm For use in the default realm, non-default realms can be equated with the default realm for authenticated name- to-local name mapping. auth_to_local_names This subsection allows you to set explicit mappings from principal names to local user names. The tag is the map- ping name and the value is the corresponding local user name. auth_to_local This tag allows you to set a general rule for mapping principal names to local user names. It will be used if there is not an explicit mapping for the principal name that is being translated. The possible values are: RULE:[<ncomps>:<format>](<regex>)s/<regex>/<text>/ Each rule has three parts: First part-Formulate the string on which to perform operations: If not present then the string defaults to the fully flattened principal minus the realm name. Otherwise the syntax is as follows: "[" <ncomps> ":" <format> "]" Where: <ncomps> is the number of expected components for this rule. If the particular principal does not have this number of components, then this rule does not apply. <format> is a string of <component> or verbatim characters to be inserted. <component> is of the form "$"<number> to select the <number>th component. <number> begins from 1. Second part-select rule validity: If not present, this rule can apply to all selec- tions. Otherwise the syntax is as follows: "(" <regex> ")" Where: <regex> is a selector regular expression. If this regular expression matches the whole pattern gen- erated from the first part, then this rule still applies. Third part-Transform rule: If not present, then the selection string is passed verbatim and is matched. Otherwise, the syntax is as follows: <rule> ... Where: <rule> is of the form: "s/" <regex> "/" <text> "/" ["g"] Regular expressions are defined in regex(5). For example: auth_to_local = RULE:[1:$...@$0](....@.*acme.com)s/@.*// The preceding maps username at ACME.COM and all sub- realms of ACME.COM to username. DEFAULT The principal name will be used as the local name. If the principal has more than one component or is not in the default realm, this rule is not applica- ble and the conversion will fail. > (Yes, I'm a bit frustrated. I finally after many hours figured out why > Thunderbird > would refuse to talk to my SSLified Dovecot IMAP server - when openssl > worked, on > some machines. I needed to install the SUNWcry packages... But now I've > finally > got GSSAPI/SSL/SMTP/IMAP working in all combinations :-) You need to install the SUNWcry packages if use of the aes256-cts-hmac-sha1-96 is desired (all other Kerberos enctypes are supported in native Solaris 10). Note support for AES 256 bit strength was not bundled with Solaris 10 to comply with US Export regulations (we recognize this is a hassle and wish this could have been bundled). -- Will Fiveash Sun Microsystems Inc. Austin, TX, USA (TZ=CST6CDT)
