Issue #17031 has been updated by Ethan Brown.
Rob Reynolds wrote: > Ethan Brown wrote: > > > > * Well-known SIDs like SYSTEM (S-1-5-18), Local Service (S-1-5-19), Network > > Service (S-1-5-20) are not globally unique and would require a host prefix > > if used in any sort of comparison. > > Do you have a reference? This is a pretty scary proposition if true. > > I agree if the wording is the distinguished name / domain of the well known > SIDs are not unique with every OS version (sometimes `BUILTIN\SYSTEM` > sometimes `NT AUTHORITY\SYSTEM`, etc). I'm not even certain if the situation I'm trying to bring to light is worth mentioning, and I don't have a domain handy to verify if it's an issue. My point here is that there could be a collision if the `objectSID` property of the `WIN32OLE` instance only returns a well-known SID like `S-1-5-19`. If a manifest tried to add `HOST1\Network Service` and `HOST2\Network Service`, I believe their `objectSID` values are the same, and only the first would be added. So in this case, the host is necessary for the comparison. I can't think of any reason that someone would want to add well-known accounts from two separate hosts to a local group. Keep in mind though that groups may contain groups so it's not implausible to add the domain admin groups from two separate domains to the local admin group, which might create the same issue. ---------------------------------------- Bug #17031: Can't add domain user account as a member of a local group https://projects.puppetlabs.com/issues/17031#change-97976 * Author: Josh Cooper * Status: Accepted * Priority: High * Assignee: Josh Cooper * Category: * Target version: 3.x * Affected Puppet version: 2.7.6 * Keywords: windows user group domain * Branch: ---------------------------------------- This is a common need when managing domain service accounts that need to be a member of the local Administrators account. I thought it would be resolved once #16581 was fixed, but there's a more fundamental issue with the group provider, so I'm filing this as a separate issue. First, it attempts to add members to the group using an ADSI path of `WinNT://WIN-QP47VOHA2P4/BIZARRO\albert,user`, but it needs to be `WinNT://WIN-QP47VOHA2P4/BIZARRO/albert,user` <pre> def add_members(*names) names.each do |name| native_group.Add(Puppet::Util::ADSI::User.uri(name)) end end </pre> It may be possible to just use the SID form `WinNT://<SID>` but I'm not sure if that will work in a non-domain environment. Second, when calculating whether the group's members are insync? it compares names: <pre> members_to_add = desired_members - current_members add_members(*members_to_add) </pre> However the ADSI provider returns current members as, e.g. `albert`. But since this doesn't match `BIZARRO\albert`, the provider will think the resource is out of sync and will attempt to re-add a user that is already a member of the group and fail: <pre> err: /Stage[main]//Group[Foobars]/members: change from albertAdministrator to BIZARRO\albert Administrator failed: Add OLE error code:80070562 in Active Directory The specified account name is already a member of the group. HRESULT error code:0x80020009 Exception occurred. </pre> Really, the group provider needs to compare the current vs desired SIDs to determine which users to add, similar to what we do in the file and scheduled_task providers. -- You have received this notification because you have either subscribed to it, or are involved in it. To change your notification preferences, please click here: http://projects.puppetlabs.com/my/account -- You received this message because you are subscribed to the Google Groups "Puppet Bugs" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/puppet-bugs. For more options, visit https://groups.google.com/groups/opt_out.
