With integrated DCE login on AIX 4, dceunixd (the helper) was using the standard POSIX calls to build all the structures needed for the local auth context. Getting the group membership for each item in the group list is part of that process. I would imagine this would also apply to PAM, as well. We saw that logins were taking a long time. (Something that makes endusers very unhappy!) It turned out everyone was in network version of staff, because we used the default user creation process. At login, dceunxid was grabbing the membership list of staff which was redirected into the DCE calls. The call returned a string list containing every user principal (>10K) in the cell, which is a significant amount of data. A sniffer or debug trace of dceunixd confirmed this. Keep in mind there's probably some point (2k users?) where this would have still been tolerable. We probably would have never taken action in that case. The point is that this is something that is best observed and optimized empirically. We also realized that with other_obj and foreign_other, the need for this type of group was non-existent. We decided on having a corresponding group for each user, set this as the primary and eliminated staff. As a secondary benefit, it allowed our users to create their own groups (a behavior which AFS usres are used to) and kept it manageable. There are a still somes issues with local vs. network groups and how to set up the exclusion lists. At the time we found this to be mainly an issue on servers. It wasn't a desktop issue then. (Of course, Murphy is always waiting in the wings when you make those sorts of assumptions ;) Regards, Chris Keith Gorlen wrote: > > > BTW, you find that with SSO the registry namespace concerns start > > getting just as tricky as the filepath namespace concerns. We had to > > change our policy for someone's default group (e.g. putting them in > > staff) because we found that the whole group membership list was passed > > as per POSIX. We adopted a model where you received a username and > > groupname that were the same "cc". (Like BSD does). > > Please elaborate--the whole group membership list is passed between > what? > -- Chris Cowan [EMAIL PROTECTED] 512-342-3635 (always) 614-677-3784 (until 6/1/98)
begin: vcard fn: Chris Cowan n: Cowan;Chris org: PSW Technologies, BSS adr;dom: 6300 Bridgepoint Pkwy;;Bldg 3, Suite 200;Austin;TX;78730; email;internet: [EMAIL PROTECTED] title: Senior Software Engineer tel;work: 512-342-3635 tel;fax: 512-345-4976 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard
