On 04/01/16 23:26, Jonathan Hunter wrote:> The story gets deeper, also.. (nothing is ever easy, right? :-)) > > Using the ldbsearch command above, I could at least view the SIDs that have > access to the OU. > > One of them should be a group called "mysecretou Managers"; I can see from > ADUC that my user is indeed still a member of this group (so far, so good). > > However, "wbinfo -s S-1-5-21-000000000-1111111111-2222222222-1234" does not > return "DOMAIN\mysecretou Managers" as it should - but rather > "DOMAIN\mysecretou Managers 2", which is not the name of the group and is > also not what shows up in ADUC. I wonder if this is actually the root of my > problems.Probably not, if I get the sid for domain Admins and then turn it back into the name, I get this: root at dc1:~# wbinfo -n Domain\ Admins S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-512 SID_DOM_GROUP (2) root at dc1:~# wbinfo -s S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-512 SAMDOM\Domain Admins 2 I tried it with Enterprise Admins and got similar results, a 2 tagged on the end, this must be a wbinfo artifact. Rowland
On 5 Jan 2016 09:59, "Rowland penny" <rpenny at samba.org> wrote:> > On 04/01/16 23:26, Jonathan Hunter wrote: >> However, "wbinfo -s S-1-5-21-000000000-1111111111-2222222222-1234" doesnot>> return "DOMAIN\mysecretou Managers" as it should - but rather >> "DOMAIN\mysecretou Managers 2", which is not the name of the group and is >> also not what shows up in ADUC. I wonder if this is actually the root ofmy>> problems. > > Probably not, if I get the sid for domain Admins and then turn it backinto the name, I get this: [...]> I tried it with Enterprise Admins and got similar results, a 2 tagged onthe end, this must be a wbinfo artifact. Phew, thank you - so it's not just me :) I hadn't used wbinfo / winbind in anger previously. So I am more confused now. Lets assume the groups are OK I.e. MYDOM\mygroup is the same as MYDOM\mygroup 2. This group is one of the SIDs showing up in the security descriptor for the errant object, and I am definitely a member of this group (my user object shows it listed via 'Member Of' in ADUC). However, I cannot view the group's members - probably related to the object for the group itself actually being inside the errant OU with the strict permissions (although I am definitely a member, as above) I'll try to use ldbedit to grant myself permissions on the OU again .. Is ldbedit safe to use: - on a running Samba server (or do I need to stop samba) - in a multi-DC environment (or do I need to run it and make the same changes on each DC) ? :) Ta J
On 5 January 2016 at 15:02, Jonathan Hunter <jmhunter1 at gmail.com> wrote:> I'll try to use ldbedit to grant myself permissions on the OU again .. Is > ldbedit safe to use: > > - on a running Samba server (or do I need to stop samba) > - in a multi-DC environment (or do I need to run it and make the same > changes on each DC) >Answering my own question here... it would appear not: http://www.spinics.net/lists/samba/msg113387.html So, I'm now not certain what the "correct" way to fix this is. I don't think I can use ldapmodify, as none of the users (me!) who should have access via LDAP actually do have access, so the AD side of things would just reject the modify request. I did deliberately remove the Administrators groups so that only my user group would have access. And I don't think I can use ldbedit, as I may screw up indexes (perhaps not, in the ntSecurityDescriptor edit case) and the changes wouldn't replicate.. unless I perhaps use ldbedit on one DC to grant the permissions back to myself, then use ADUC pointed at that DC to change the OU entry, which should trigger a replication of the current entry across to other DCs.... I guess there may be no other way, though..? -- "If we knew what it was we were doing, it would not be called research, would it?" - Albert Einstein