[OpenAFS-devel] OpenAFS-devel] aklog on MacOS X was Re: Service Ticket Questions
Henry B. Hotz
hbhotz@oxy.edu
Fri, 7 Apr 2006 15:29:53 -0700
Some more background information. If you get the NullAuthPlugin
example from the developer web site it contains the following
interesting list of authorization services mechanism context values.
(Yes, I've gotten indications that it's OK to release this level of
info outside the Apple developer community.)
> static const KeyInfo kStateKeys[] = {
> // context keys from a typical system (found using debugger)
>
> { "uid", kUID },
> { "gid", kGID },
> { "home", kString0 },
> { "longname", kString0 },
> { "username", kString0 },
> { "password", kString0 },
> { "shell", kString0 },
>
> // hint keys from a typical system (found using debugger)
>
> { "authorize-right", kString },
> { "authorize-rule", kString },
> { "client-path", kString },
> { "client-pid", kPID },
> { "client-type", kOSType },
> { "client-uid", kUID },
> { "creator-pid", kPID },
> { "tries", kUInt32 },
>
> // other keys found by grovelling through source code
>
> { "suggested-user", kUnknown },
> { "require-user-in-group", kUnknown },
> { "prompt", kUnknown },
> { "reason", kUnknown },
> { "token-name", kUnknown },
> { "afp_dir", kString0 },
> { "kerberos-principal", kUnknown },
!! This is the one that you need to set in order to make the "sso"
mechanism do its thing!
Of course it's possible that the builtin:krb5login mechanism has been
fixed in 10.4.6 and it would be easier to change sso to krb5login
than to put in a new, custom plugin. Both of them will return
successful regardless and not block login. I haven't tested sso to
see if it really works yet either.
Probably do some experiments next week and will let people know what
happens.
> { "mountpoint", kString0 },
> { "new-password", kUnknown },
> { "show-add-to-keychain", kUnknown },
> { "add-to-keychain", kUnknown },
> { "Home_Dir_Mount_Result", kSInt32 },
> { "homeDirType", kSInt32 },
>
> // The getuserinfo authentication mechanism copies all of the
> user's
> // Open Directory attributes to the hints (?, or context?). So we
> // look for the standard OD user attributes.
> //
> // AFAIK all of these are of type kString (because getuserinfo
> // only copies across string values), but I've only set the type
> // to string for those that I've seen in the wild. The remainder
> // stay as type kUnknown until I see a concrete example.
>
> { kDS1AttrAdminLimits, kUnknown },
> { kDS1AttrAdminStatus, kUnknown },
> { kDS1AttrAlternateDatastoreLocation, kUnknown },
> { kDS1AttrAuthenticationHint, kUnknown },
> { kDS1AttrChange, kUnknown },
> { kDS1AttrComment, kUnknown },
> { kDS1AttrDistinguishedName, kString },
> { kDS1AttrExpire, kUnknown },
> { kDS1AttrFirstName, kUnknown },
> { kDS1AttrGeneratedUID, kString },
> { kDS1AttrHomeDirectorySoftQuota, kUnknown },
> { kDS1AttrHomeDirectoryQuota, kUnknown },
> { kDS1AttrHomeLocOwner, kUnknown },
> { kDS1AttrInternetAlias, kUnknown },
> { kDS1AttrLastName, kString },
> { kDS1AttrMailAttribute, kUnknown },
> { kDS1AttrMiddleName, kUnknown },
> { kDS1AttrNFSHomeDirectory, kString },
> { kDS1AttrOriginalNFSHomeDirectory, kUnknown },
> { kDS1AttrPassword, kString },
> { kDS1AttrPasswordPlus, kString },
> { kDS1AttrPicture, kUnknown },
> { kDS1AttrPrimaryGroupID, kString },
> { kDS1AttrRealUserID, kString },
> { kDS1AttrUniqueID, kString },
> { kDS1AttrUserShell, kString },
> { kDSNAttrAddressLine1, kUnknown },
> { kDS1StandardAttrHomeLocOwner, kUnknown },
> { kDSNAttrAddressLine2, kUnknown },
> { kDSNAttrAddressLine3, kUnknown },
> { kDSNAttrAreaCode, kUnknown },
> { kDSNAttrAuthenticationAuthority, kPlistOrString },
> { kDSNAttrBuilding, kUnknown },
> { kDSNAttrCity, kUnknown },
> { kDSNAttrCountry, kUnknown },
> { kDSNAttrDepartment, kUnknown },
> { kDSNAttrEMailAddress, kUnknown },
> { kDSNAttrFaxNumber, kUnknown },
> { kDSNAttrGroupMembers, kUnknown },
> { kDSNAttrGroupMembership, kUnknown },
> { kDSNAttrHomeDirectory, kString },
> { kDSNAttrIMHandle, kUnknown },
> { kDSNAttrJobTitle, kUnknown },
> { kDSNAttrMobileNumber, kUnknown },
> { kDSNAttrNamePrefix, kUnknown },
> { kDSNAttrNameSuffix, kUnknown },
> { kDSNAttrNestedGroups, kUnknown },
> { kDSNAttrNetGroups, kUnknown },
> { kDSNAttrNickName, kUnknown },
> { kDSNAttrOrganizationName, kUnknown },
> { kDSNAttrOriginalHomeDirectory, kUnknown },
> { kDSNAttrPagerNumber, kUnknown },
> { kDSNAttrPhoneNumber, kUnknown },
> { kDSNAttrPostalAddress, kUnknown },
> { kDSNAttrPostalCode, kUnknown },
> { kDSNAttrState, kUnknown },
> { kDSNAttrStreet, kUnknown }
On Apr 5, 2006, at 4:04 PM, Henry B. Hotz wrote:
> On Apr 5, 2006, at 2:30 PM, Ragnar Sundblad wrote:
>
>> On 5 apr 2006, at 23.03, Henry B. Hotz wrote:
>>
>>> Yes, I'm studying that as well. It's easy to stick something in
>>> system.login.screensaver that works for a single user. Not so
>>> easy to figure something that preserves all the admin override
>>> options.
>>
>> What do you mean with preserving the admin override options?
>> I just put "builtin:krb5authnoverify,privileged" on the right
>> "system.login.console"
>> and the rule "authenticate", and that does it for my needs. I
>> think. Do you want
>> something else?
>
> You're finding relevant places the "authinternal" mechanism is
> referenced and replacing them. Not unreasonable. Have you tried
> removing the one authenticate rule to see if it matters? I don't
> see that rule referenced anywhere inside the file (though invisible
> stuff might reference it).
>
> I'm looking at the rights that might be relevant:
> system.login.console, system.login.done, and
> system.login.screensaver. The last references rule authenticate-
> session-owner-or-admin, which has three (I think this is the right
> grouping) ways to work: allow-root, class user/group admin, and
> class user/session-owner. Ought to be able to replace session-
> owner with something appropriate that also does Kerberos. Of
> course maybe the right solution is to replace something lower
> level. I'm waiting for Apple feedback on the subject.
>
> I expect you understand the risks of using krb5:authnoverify. It's
> great for testing though.
>
>>> I haven't folded this in with Apple, yet, but if you use the
>>> "switch user" button from the screen saver it does exercise
>>> system.login.console, but the resulting Kerberos tickets don't
>>> get saved for the resulting user.
>>
>> It does for me, actually. This seems to work for me. I wonder what
>> the
>> difference is.
>>
>>> This is true if you are switching to yourself, anyway.
>>
>> If I select another user from the user switching menu (yes, I have
>> the
>> "Show list of users" enabled, I have three user accounts on this
>> machine :-),
>> a tgt for the new user will be put in the prev user's ticket
>> cache, and the
>> principal name for that ticket cache will be set to the new
>> user's. This really
>> is broken and must be reported. If I go via selecting Login Window
>> in the menu,
>> it seems to work, so if you don't have "Show list of users" it
>> might work.
>
> That's a good test and pretty revealing. Please file a bug on it!
>
> I've been testing against our production Kerberos so far, and I
> only have one user account there.
10.4.6 doesn't seem to have affected this problem. There are
apparently some bugs in the system kerberos auth mechanisms that are
fixed in 10.4.6, but I wasn't seeing those anyway because I was using
the example plug-in (with my patch).
------------------------------------------------------------------------
----
The opinions expressed in this message are mine,
not those of Caltech, JPL, NASA, or the US Government.
Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu