On Thu, May 14, 2009 at 12:34:00PM +0200, Florian Manschwetus wrote: > Am 14.05.2009 12:14, schrieb Julian Pullen: > >I did look at the code changes and my view is that this support for AD > >groups > >really belongs to nss_ad. Since nss_ad currently does not support login > >we need to take a pragmatic approach. > Login in ad enviroment should be done via kerberos anyway.
No, that would be authentication. The system still needs to know a lot of information about the user, such as home directory, UID, GIDs, ... Now, some of that does come in the user's Kerberos V Ticket, in the PAC. But that's not enough, for a variety of reasons (e.g., we don't get IDMU/SFU attributes in the PAC, so we could use the user's Windows home directory, but that might not be what the user expects on Unix). Therefore we need a name service switch backend to support AD user logins. > But nss_ad uses the idmap approach to generate a local unique mapping on > the fly, what is totally different to this method. Yes. And no. We're looking at adding support to idmapd for using uidNumber and gidNumber directly for users/groups in the host's domain. In that case the UIDs and GIDs will come straight from AD. > But it would be nice to modify idmap in a way that it uses such data > from ad if it is present (as I read the docs, it should do so already > but in fact I was unable to configure it this way) Right. > Furthermore this makes a more sophisticated group layout possible (not > only with MS AD LDAP) also this is supported by the padl nss_ldap stuff > used for linux, so this is something that should work anyway. Can you elaborate? > This topic also introduces a problem with the static layout of > membership management in solaris kernel, which hard limits the > group-count per user extremely (normally 16/32, manually modification > possible, but increases RAM usage quickly due to static reservation). An > unacceptable limitation for modern centrally managed IT-Infrastructures. Look again. Solaris already has unlimited supplementary SID support in cred_t. Expanding ngroups_max to support more than 32 supplementary GIDs would not be difficult (the main issue to address is which GIDs should AUTH_SYS use when there are more than 16 supplementary GIDs). Nico --
