Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Samba] LDAP permissions - ldbedit/ldapmodify?
368 views
Skip to first unread message
Jonathan Hunter
Jan 3, 2016, 8:50:04 PM1/3/16
to
Hi,
A while ago I successfully set permissions on a section of my LDAP / AD
tree, using either ADUC or ADSIEDIT (I forget which). These permissions
allowed my own user to access this section of the tree; I removed
permissions for 'Domain Admins' etc. to ensure that others would not be
able to view or change the data - this has worked great for many months.
I have just tried to add a new entry to this section of the tree, but I
appear to have locked myself out somehow. I don't know if this is because I
recently made some idmap changes and therefore my UID has changed, or for
some other reason - so I am asking on here to find out where the LDAP
permissions are stored. Hopefully I can reset the permissions and regain
access.
I can view the data using ldbsearch when logged in as root on the DC itself
- but how do I view the permissions and edit them from the commandline? The
data is all present and correct:
mydc1# ldbsearch -H /usr/local/samba/private/sam.ldb -s sub -b
ou=mysecretou,dc=mydomain,dc=org,dc=uk
[...]
# returned 127 records
# 127 entries
# 0 referrals
Even logging in as MYDOMAIN\Administrator I can't view or change the
permissions of ou=mysecretou using ADUC/ADSIEdit (This is exactly as I
originally set it). So, how can I change the permissions from the
commandline? Do I use ldbedit on a with different parameters, or on a
separate ldb file? Is there a "ldapmodify" command I can run - this would
presumably work better, as any changes would then be replicated to other
DCs as well.
Thanks!
Jonathan
--
"If we knew what it was we were doing, it would not be called research,
would it?"
- Albert Einstein
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
A while ago I successfully set permissions on a section of my LDAP / AD
tree, using either ADUC or ADSIEDIT (I forget which). These permissions
allowed my own user to access this section of the tree; I removed
permissions for 'Domain Admins' etc. to ensure that others would not be
able to view or change the data - this has worked great for many months.
I have just tried to add a new entry to this section of the tree, but I
appear to have locked myself out somehow. I don't know if this is because I
recently made some idmap changes and therefore my UID has changed, or for
some other reason - so I am asking on here to find out where the LDAP
permissions are stored. Hopefully I can reset the permissions and regain
access.
I can view the data using ldbsearch when logged in as root on the DC itself
- but how do I view the permissions and edit them from the commandline? The
data is all present and correct:
mydc1# ldbsearch -H /usr/local/samba/private/sam.ldb -s sub -b
ou=mysecretou,dc=mydomain,dc=org,dc=uk
[...]
# returned 127 records
# 127 entries
# 0 referrals
Even logging in as MYDOMAIN\Administrator I can't view or change the
permissions of ou=mysecretou using ADUC/ADSIEdit (This is exactly as I
originally set it). So, how can I change the permissions from the
commandline? Do I use ldbedit on a with different parameters, or on a
separate ldb file? Is there a "ldapmodify" command I can run - this would
presumably work better, as any changes would then be replicated to other
DCs as well.
Thanks!
Jonathan
--
"If we knew what it was we were doing, it would not be called research,
would it?"
- Albert Einstein
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
Rowland penny
Jan 4, 2016, 5:40:04 AM1/4/16
to
if you want to see it, you will have to explicitly ask for it e.g.
ldbedit -e nano -H /usr/local/samba/private/sam.ldb -b
OU=SUDOers,DC=samdom,DC=example,DC=com -s sub
"(&(objectClass=organizationalUnit)(objectCategory=organizationalUnit))"
nTSecurityDescriptor
Which will return something like this:
# editing 1 records
# record 1
dn: OU=SUDOers,DC=samdom,DC=example,DC=com
nTSecurityDescriptor:
O:DAG:DAD:AI(A;CI;RPLCRC;;;DU)(A;;RPWPCRCCDCLCLORCWOWDSD
DTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(OA;;CCDC;bf967a86-0de6-11d0-a2
85-00aa003049e2;;AO)(OA;;CCDC;bf967aba-0de6-11d0-a285-00aa003049e2;;AO)(OA;;C
CDC;bf967a9c-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aa8-0de6-11d0-a28
5-00aa003049e2;;PO)(A;;RPLCLORC;;;AU)(A;;RPLCLORC;;;ED)(OA;;CCDC;4828cc14-143
7-45bc-9b07-ad6f015e5f28;;AO)(OA;CIIOID;RP;4c164200-20c0-11d0-a768-00aa006e05
29;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;4c164200-20c0-11d0-a
768-00aa006e0529;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;5f2020
10-79a5-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CI
IOID;RP;5f202010-79a5-11d0-9020-00c04fc2d4cf;bf967aba-0de6-11d0-a285-00aa0030
49e2;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;4828cc14-1437-45bc
-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;bc0ac240-79a9-11d0-9020-00c04fc2d4cf;bf96
7aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP;59ba2f42-79a2-11d0-9020-00c
04fc2d3cf;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RP;59ba2f42-79a2
-11d0-9020-00c04fc2d3cf;bf967aba-0de6-11d0-a285-00aa003049e2;RU)(OA;CIIOID;RP
;037088f8-0ae1-11d2-b422-00a0c968f939;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU
)(OA;CIIOID;RP;037088f8-0ae1-11d2-b422-00a0c968f939;bf967aba-0de6-11d0-a285-0
0aa003049e2;RU)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f608;bf967a86-0d
e6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-854e-00a0c983f6
08;bf967a9c-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RP;b7c69e6d-2cc7-11d2-8
54e-00a0c983f608;bf967aba-0de6-11d0-a285-00aa003049e2;ED)(OA;CIIOID;RPLCLORC;
;4828cc14-1437-45bc-9b07-ad6f015e5f28;RU)(OA;CIIOID;RPLCLORC;;bf967a9c-0de6-1
1d0-a285-00aa003049e2;RU)(OA;CIIOID;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003
049e2;RU)(OA;CIID;RPWPCR;91e647de-d96f-4b70-9557-d63ff4f3ccd8;;PS)(A;CIID;RPW
PCRCCDCLCLORCWOWDSDDTSW;;;EA)(A;CIID;LC;;;RU)(A;CIID;RPWPCRCCLCLORCWOWDSDSW;;
;BA)S:AI(OU;CIIDSA;WP;f30e3bbe-9ff0-11d1-b603-0000f80367c1;bf967aa5-0de6-11d0
-a285-00aa003049e2;WD)(OU;CIIDSA;WP;f30e3bbf-9ff0-11d1-b603-0000f80367c1;bf96
7aa5-0de6-11d0-a285-00aa003049e2;WD)
For a start on what the above means, see here:
http://www.netid.washington.edu/documentation/domains/sddl.aspx
Rowland
Jonathan Hunter
Jan 4, 2016, 5:40:04 PM1/4/16
to
Thank you, Rowland!
On 4 January 2016 at 10:36, Rowland penny <rpe...@samba.org> wrote:
> On 04/01/16 01:43, Jonathan Hunter wrote:
>
>> I can view the data using ldbsearch when logged in as root on the DC
>> itself
>> - but how do I view the permissions and edit them from the commandline?
>>
>
by adding "--show-binary" to the end of the ldbsearch command I was
running, I could get a more user-readable version of the security
descriptor:
# ldbsearch -H /usr/local/samba/private/sam.ldb -s base -b
ou=mysecretou,dc=mydomain,dc=org,dc=uk nTSecurityDescriptor --show-binary
# record 1
dn: ou=mysecretou,dc=mydomain,DC=ninja,DC=org,DC=uk
nTSecurityDescriptor: NDR: struct security_descriptor
revision : SECURITY_DESCRIPTOR_REVISION_1 (1)
type : 0x9d17 (40215)
1: SEC_DESC_OWNER_DEFAULTED
1: SEC_DESC_GROUP_DEFAULTED
1: SEC_DESC_DACL_PRESENT
0: SEC_DESC_DACL_DEFAULTED
[...]
0: SEC_DESC_RM_CONTROL_VALID
1: SEC_DESC_SELF_RELATIVE
owner_sid : *
owner_sid :
S-1-5-21-197107965-2004198405-1252158227-512
group_sid : *
group_sid :
S-1-5-21-197107965-2004198405-1252158227-512
sacl : *
sacl: struct security_acl
revision : SECURITY_ACL_REVISION_ADS (4)
size : 0x0078 (120)
num_aces : 0x00000002 (2)
[...]
I assume that it isn't safe to use ldbedit in a multi-DC environment,
though, particularly whilst Samba is running.. but maybe I am
under-estimating its capabilities? From https://ldb.samba.org/ it is "Safe
multi-reader, multi-writer, using byte range locking".. but even if so,
what would tell Samba to replicate the change I just made to the other DCs?
It looks like I can use ldbedit with "-H ldap://localhost -P" - but via
this route, I can't view the nTSecurityDescriptor attribute (presumably
because I don't have permissions)
To make my change, then, would I have to shut down Samba on all DCs; make
the change with ldbedit independently on all DCs; then restart Samba? Or is
there another way of applying the change on multiple DCs, perhaps?
Many thanks :)
Jonathan
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
On 4 January 2016 at 10:36, Rowland penny <rpe...@samba.org> wrote:
> On 04/01/16 01:43, Jonathan Hunter wrote:
>
>> I can view the data using ldbsearch when logged in as root on the DC
>> itself
>> - but how do I view the permissions and edit them from the commandline?
>>
>
> They are stored in a hidden attribute called 'nTSecurityDescriptor' and if
> you want to see it, you will have to explicitly ask for it e.g.
>
> ldbedit -e nano -H /usr/local/samba/private/sam.ldb -b
> OU=SUDOers,DC=samdom,DC=example,DC=com -s sub
> "(&(objectClass=organizationalUnit)(objectCategory=organizationalUnit))"
> nTSecurityDescriptor
>
Perfect, thank you - I can now see this attribute. I also figured out that
> you want to see it, you will have to explicitly ask for it e.g.
>
> ldbedit -e nano -H /usr/local/samba/private/sam.ldb -b
> OU=SUDOers,DC=samdom,DC=example,DC=com -s sub
> "(&(objectClass=organizationalUnit)(objectCategory=organizationalUnit))"
> nTSecurityDescriptor
>
by adding "--show-binary" to the end of the ldbsearch command I was
running, I could get a more user-readable version of the security
descriptor:
# ldbsearch -H /usr/local/samba/private/sam.ldb -s base -b
ou=mysecretou,dc=mydomain,dc=org,dc=uk nTSecurityDescriptor --show-binary
# record 1
dn: ou=mysecretou,dc=mydomain,DC=ninja,DC=org,DC=uk
nTSecurityDescriptor: NDR: struct security_descriptor
revision : SECURITY_DESCRIPTOR_REVISION_1 (1)
type : 0x9d17 (40215)
1: SEC_DESC_OWNER_DEFAULTED
1: SEC_DESC_GROUP_DEFAULTED
1: SEC_DESC_DACL_PRESENT
0: SEC_DESC_DACL_DEFAULTED
[...]
0: SEC_DESC_RM_CONTROL_VALID
1: SEC_DESC_SELF_RELATIVE
owner_sid : *
owner_sid :
S-1-5-21-197107965-2004198405-1252158227-512
group_sid : *
group_sid :
S-1-5-21-197107965-2004198405-1252158227-512
sacl : *
sacl: struct security_acl
revision : SECURITY_ACL_REVISION_ADS (4)
size : 0x0078 (120)
num_aces : 0x00000002 (2)
[...]
I assume that it isn't safe to use ldbedit in a multi-DC environment,
though, particularly whilst Samba is running.. but maybe I am
under-estimating its capabilities? From https://ldb.samba.org/ it is "Safe
multi-reader, multi-writer, using byte range locking".. but even if so,
what would tell Samba to replicate the change I just made to the other DCs?
It looks like I can use ldbedit with "-H ldap://localhost -P" - but via
this route, I can't view the nTSecurityDescriptor attribute (presumably
because I don't have permissions)
To make my change, then, would I have to shut down Samba on all DCs; make
the change with ldbedit independently on all DCs; then restart Samba? Or is
there another way of applying the change on multiple DCs, perhaps?
Many thanks :)
Jonathan
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
--
"If we knew what it was we were doing, it would not be called research,
would it?"
- Albert Einstein
"If we knew what it was we were doing, it would not be called research,
would it?"
- Albert Einstein
Jonathan Hunter
Jan 4, 2016, 6:30:03 PM1/4/16
to
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.
After I removed a number of old records from idmap.ldb a few weeks back
(you helped me a lot with xidNumber details, thank you - separate thread
here entitled "idmap & migration to rfc2307"), I did spot that a few groups
started to be displayed in this manner on my DC, i.e. "DOMAIN\My Group 2"
rather than "DOMAIN\My Group" as would be shown on Windows, and so on.
So far I have simply ignored these, as on the Windows side everything
seemed to be working fine and it was yet another Samba wierdness that I
needed to track down and debug.. but perhaps these issues are indeed
related :(
I did edit idmap.ldb and remove a number of old entries with invalid
xidNumbers; but at the time I couldn't figure out where the "DOMAIN\My
Group 2" entries were coming from, so I just left them :(
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.
After I removed a number of old records from idmap.ldb a few weeks back
(you helped me a lot with xidNumber details, thank you - separate thread
here entitled "idmap & migration to rfc2307"), I did spot that a few groups
started to be displayed in this manner on my DC, i.e. "DOMAIN\My Group 2"
rather than "DOMAIN\My Group" as would be shown on Windows, and so on.
So far I have simply ignored these, as on the Windows side everything
seemed to be working fine and it was yet another Samba wierdness that I
needed to track down and debug.. but perhaps these issues are indeed
related :(
I did edit idmap.ldb and remove a number of old entries with invalid
xidNumbers; but at the time I couldn't figure out where the "DOMAIN\My
Group 2" entries were coming from, so I just left them :(
Rowland penny
Jan 5, 2016, 5:00:04 AM1/5/16
to
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
> 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.
into the name, I get this:
root@dc1:~# wbinfo -n Domain\ Admins
S-1-5-21-xxxxxxxxxx-yyyyyyyyyy-zzzzzzzzzz-512 SID_DOM_GROUP (2)
root@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
Jonathan Hunter
Jan 5, 2016, 10:10:04 AM1/5/16
to
On 5 Jan 2016 09:59, "Rowland penny" <rpe...@samba.org> wrote:
>
> On 04/01/16 23:26, Jonathan Hunter wrote:
>> 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:
[...]
>
> On 04/01/16 23:26, Jonathan Hunter wrote:
>> 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:
> I tried it with Enterprise Admins and got similar results, a 2 tagged on
the end, this must be a wbinfo artifact.
Phew, thank you - so it's not just me :) I hadn't used wbinfo / winbind in
the end, this must be a wbinfo artifact.
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
Jonathan Hunter
Jan 5, 2016, 4:30:04 PM1/5/16
to
On 5 January 2016 at 15:02, Jonathan Hunter <jmhu...@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:
> 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)
>
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
Rowland penny
Jan 5, 2016, 5:00:04 PM1/5/16
to
On 05/01/16 21:24, Jonathan Hunter wrote:
> On 5 January 2016 at 15:02, Jonathan Hunter <jmhu...@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
> On 5 January 2016 at 15:02, Jonathan Hunter <jmhu...@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..?
>
>
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
Jonathan Hunter
Jan 5, 2016, 9:10:02 PM1/5/16
to
Thank you Rowland.
On 5 January 2016 at 21:53, Rowland penny <rpe...@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
On 5 January 2016 at 21:53, Rowland penny <rpe...@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.
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
0 new messages