[Samba] LDAP permissions - ldbedit/ldapmodify?

Jonathan Hunter jmhunter1 at gmail.com
Wed Jan 6 02:04:08 UTC 2016

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 :)


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

More information about the samba mailing list