samba - Jan 2016 - LDAP permissions - ldbedit/ldapmodify?

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

On 05/01/16 21:24, Jonathan Hunter wrote:
> 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..?
>
>
I think if you carefully read the link that you posted, Andrew said 
don't edit the files in sam.ldb.d directly. As far as I am aware, you 
can edit the sam.ldb file, in fact when I was trying out sssd with sudo 
sometime ago (before I got winbind to work for me), I manually edited an 
nTSecurityDescriptor attribute.

Whilst it worked for me, try at your own risk in a test environment.

Rowland

Thank you Rowland.

On 5 January 2016 at 21:53, Rowland penny <rpenny at samba.org>
wrote:
>
> I think if you carefully read the link that you posted, Andrew said
don't
> edit the files in sam.ldb.d directly. As far as I am aware, you can edit
> the sam.ldb file, in fact when I was trying out sssd with sudo sometime ago
> (before I got winbind to work for me), I manually edited an
> nTSecurityDescriptor attribute.
>
> Whilst it worked for me, try at your own risk in a test environment.

I have done some more digging, in the meantime. This might not actually be
a Samba issue - it looks like some weird bug in ADUC maybe.. I've left
details below in case others encounter the same in future.

Thanks to your earlier info regarding the ntSecurityDescriptor attribute, I
was able to look into a few things afterwards. I found that:
- The ntSecurityDescriptor for this OU is, as far as I can tell (using
ldbsearch locally) identical on all DCs - which is of course a good thing
- ADUC only fails to show me the contents of this 'restricted' OU when I
connect to _one_ of my DCs (the first one I tried - hence my assuming this
was a permissions issue throughout)
- ADUC works perfectly when I point it at any of my other three DCs - just
not the one DC I started with.

Thinking that the DC was to blame, despite the ntSecurityDescriptor being
the same, I restarted Samba (I even tried stopping Samba and ran 'net cache
flush' for all the good that it might do) - but no luck; ADUC still
didn't
allow me access to the OU via this DC.

Finally, I deleted my entire user profile (C:\Users\myusername) from the
machine I had been running ADUC from (it's a VM, so I can play..) and then
finally I could view the OU as expected, on all four DCs. There must have
been some cached information or some bit of data that led to ADUC (and
weirdly, also ADSIEdit when logged in as my user) thinking that it could
not access the OU in question.

So I am chalking this one up to some kind of bug in ADUC, or possibly some
kind of interaction failure. If I get a chance, I'll try and use Process
Explorer to figure out what file(s) or registry keys need to be removed in
order to effectively clear the cache for my user - removing the entire
profile seems a bit extreme - but I think it's safe to say that this is an
odd Windows 7 / ADUC issue. (I'm not sure exactly what, though, as it
affects both ADUC and ADSIEdit)

So, thanks for the info regarding ntSecurityDescriptor - that gave me
enough info to follow the path that showed this not to be a Samba issue
after all :-)

For reference, if anyone has the same in future, the observed behaviour
from ADUC was as follows:
- The OU itself did not appear at its proper place in the tree view pane
- The OU did show as an item in the main item list view, but as type
"Unknown" rather than as type "Organizational Unit"
- Viewing Properties of the OU shows the message "The Active Directory
Domain Services object could not be displayed. Unable to view attribute or
value. You may not have permissions to view this object."

Thanks :)

Jonathan

-- 
"If we knew what it was we were doing, it would not be called research,
would it?"
      - Albert Einstein