Samba 4 insufficientAccessRights when modifying Configuration
Locked
12
12
Samba 4 insufficientAccessRights when modifying Configuration
 
|
All,
I'm getting the following (seen using wireshark): LDAPMessage modifyResponse(15) insufficientAccessRights (00002098: Object CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti has no write property access) when trying to modify the schema from a software installer. The installer is trying to add a value to adminContextMenu of "2,{11330101-C4C8-11D6-B1DF-000476962053}" If I try to do the same thing with ADSI, it appears to work. Unfortunately there are MANY such modifications the installer needs to do, so doing it manually would be extremely tedious. Is there a reason why the installer can't write but ADSI can? Thanks, Brian |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
Are you running the installer as Administrator?
On Fri, Jul 27, 2012 at 2:11 PM, Brian C. Huffman < [hidden email]> wrote: > All, > > I'm getting the following (seen using wireshark): > LDAPMessage modifyResponse(15) insufficientAccessRights (00002098: Object > CN=group-Display,CN=407,CN=**DisplaySpecifiers,CN=**Configuration,DC=xmen,DC=eti > has no write property access) > > when trying to modify the schema from a software installer. > > The installer is trying to add a value to adminContextMenu of > "2,{11330101-C4C8-11D6-B1DF-**000476962053}" > > If I try to do the same thing with ADSI, it appears to work. Unfortunately > there are MANY such modifications the installer needs to do, so doing it > manually would be extremely tedious. > > Is there a reason why the installer can't write but ADSI can? > > Thanks, > Brian > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Yep - domain administrator.
On 7/27/12 7:27 AM, Nadezhda Ivanova wrote: > Are you running the installer as Administrator? > > On Fri, Jul 27, 2012 at 2:11 PM, Brian C. Huffman > <[hidden email] <mailto:[hidden email]>> > wrote: > > All, > > I'm getting the following (seen using wireshark): > LDAPMessage modifyResponse(15) insufficientAccessRights (00002098: > Object > CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > has no write property access) > > when trying to modify the schema from a software installer. > > The installer is trying to add a value to adminContextMenu of > "2,{11330101-C4C8-11D6-B1DF-000476962053}" > > If I try to do the same thing with ADSI, it appears to work. > Unfortunately there are MANY such modifications the installer > needs to do, so doing it manually would be extremely tedious. > > Is there a reason why the installer can't write but ADSI can? > > Thanks, > Brian > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Theoretically to modify the Configuration or the Schema you need to be
Enterprise admin, as these are forest-wide changes... On Fri, Jul 27, 2012 at 2:37 PM, Brian C. Huffman < [hidden email]> wrote: > Yep - domain administrator. > > > On 7/27/12 7:27 AM, Nadezhda Ivanova wrote: > >> Are you running the installer as Administrator? >> >> On Fri, Jul 27, 2012 at 2:11 PM, Brian C. Huffman < >> [hidden email] <mailto:bhuffman@**etinternational.com<[hidden email]>>> >> wrote: >> >> All, >> >> I'm getting the following (seen using wireshark): >> LDAPMessage modifyResponse(15) insufficientAccessRights (00002098: >> Object >> CN=group-Display,CN=407,CN=**DisplaySpecifiers,CN=** >> Configuration,DC=xmen,DC=eti >> has no write property access) >> >> when trying to modify the schema from a software installer. >> >> The installer is trying to add a value to adminContextMenu of >> "2,{11330101-C4C8-11D6-B1DF-**000476962053}" >> >> If I try to do the same thing with ADSI, it appears to work. >> Unfortunately there are MANY such modifications the installer >> needs to do, so doing it manually would be extremely tedious. >> >> Is there a reason why the installer can't write but ADSI can? >> >> Thanks, >> Brian >> >> >> > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Sorry - I should have been clear. I'm running as "Administrator" which
is a member of the Enterprise Admins (and also Schema Admins, just in case). -b On 07/27/2012 08:01 AM, Nadezhda Ivanova wrote: > Theoretically to modify the Configuration or the Schema you need to be > Enterprise admin, as these are forest-wide changes... > > On Fri, Jul 27, 2012 at 2:37 PM, Brian C. Huffman > <[hidden email] <mailto:[hidden email]>> > wrote: > > Yep - domain administrator. > > > On 7/27/12 7:27 AM, Nadezhda Ivanova wrote: > > Are you running the installer as Administrator? > > On Fri, Jul 27, 2012 at 2:11 PM, Brian C. Huffman > <[hidden email] > <mailto:[hidden email]> > <mailto:[hidden email] > <mailto:[hidden email]>>> wrote: > > All, > > I'm getting the following (seen using wireshark): > LDAPMessage modifyResponse(15) insufficientAccessRights > (00002098: > Object > > CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > has no write property access) > > when trying to modify the schema from a software installer. > > The installer is trying to add a value to adminContextMenu of > "2,{11330101-C4C8-11D6-B1DF-000476962053}" > > If I try to do the same thing with ADSI, it appears to work. > Unfortunately there are MANY such modifications the installer > needs to do, so doing it manually would be extremely tedious. > > Is there a reason why the installer can't write but ADSI can? > > Thanks, > Brian > > > > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
On Fri, 2012-07-27 at 09:20 -0400, Brian C. Huffman wrote:
> Sorry - I should have been clear. I'm running as "Administrator" which > is a member of the Enterprise Admins (and also Schema Admins, just in case). If this is all being run as the same user, then the next step is to get a network trace of the operations, and see if we can figure out how the installer's operations differ from the MMC operations. This will let us know if we can find a way the (presumably) subtly different operations take different code paths. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
In reply to this post by Brian C. Huffman
On 07/27/2012 04:11 AM, Brian C. Huffman wrote:
> All, > > I'm getting the following (seen using wireshark): > LDAPMessage modifyResponse(15) insufficientAccessRights (00002098: > Object > CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > has no write property access) > > when trying to modify the schema from a software installer. > > The installer is trying to add a value to adminContextMenu of > "2,{11330101-C4C8-11D6-B1DF-000476962053}" > > If I try to do the same thing with ADSI, it appears to work. > Unfortunately there are MANY such modifications the installer needs to > do, so doing it manually would be extremely tedious. > unsufficient rights problem for administrator. Then the next questions are: * is there any specified control during the modify either by your software or by ADSI ? * are ADSI and your installer doing the exact same modification * are you sure the installer runs with the administrator rights (it can be a bug that leads it to use a non priviledged account) Btw it seems that your installer has issue not with the schema but just the configuration > Is there a reason why the installer can't write but ADSI can? > > Thanks, > Brian Matthieu. |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
In reply to this post by Andrew Bartlett
I tried using a standard tcpdump -w and then loading the result into
wireshark, but the output for when I use ADSI (MMC) is completely different and I don't see anything recognizable there. In fact, wireshark doesn't even detect the LDAP protcol at all - it's showing just TCP in the protocol field for all packets. Might it be encrypted? If so, how would we go about finding a useful trace to compare? Brian On 07/27/2012 08:55 PM, Andrew Bartlett wrote: > On Fri, 2012-07-27 at 09:20 -0400, Brian C. Huffman wrote: >> Sorry - I should have been clear. I'm running as "Administrator" which >> is a member of the Enterprise Admins (and also Schema Admins, just in case). > If this is all being run as the same user, then the next step is to get > a network trace of the operations, and see if we can figure out how the > installer's operations differ from the MMC operations. > > This will let us know if we can find a way the (presumably) subtly > different operations take different code paths. > > Andrew Bartlett > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Ok. I got the encryption figured out.
So, there are two things that ADSI does differently: 1) It appears in wireshark that ADSI does two modify requests (they look like duplicates to me, but I could be wrong). 2) ADSI does a "replace" whereas the installer does an "add" (the 1st entry "1,{08...}" was already there) (ADSI): LDAPMessage modifyRequest(291) "CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti" messageID: 291 protocolOp: modifyRequest (6) modifyRequest object: CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti modification: 1 item modification item operation: replace (2) modification adminContextMenu type: adminContextMenu vals: 2 items 1,{08eb4fa6-6ffd-11d1-b0e0-00c04fd8dca6} 2,{11330101-C4C8-11D6-B1DF-000476962053} (Installer): LDAPMessage modifyRequest(25) "CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti" messageID: 25 protocolOp: modifyRequest (6) modifyRequest object: CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti modification: 1 item modification item operation: add (0) modification adminContextMenu type: adminContextMenu vals: 1 item 2,{11330101-C4C8-11D6-B1DF-000476962053} -b On 07/30/2012 09:47 AM, Brian C. Huffman wrote: > I tried using a standard tcpdump -w and then loading the result into > wireshark, but the output for when I use ADSI (MMC) is completely > different and I don't see anything recognizable there. In fact, > wireshark doesn't even detect the LDAP protcol at all - it's showing > just TCP in the protocol field for all packets. > > Might it be encrypted? If so, how would we go about finding a useful > trace to compare? > > Brian > > On 07/27/2012 08:55 PM, Andrew Bartlett wrote: >> On Fri, 2012-07-27 at 09:20 -0400, Brian C. Huffman wrote: >>> Sorry - I should have been clear. I'm running as "Administrator" which >>> is a member of the Enterprise Admins (and also Schema Admins, just >>> in case). >> If this is all being run as the same user, then the next step is to get >> a network trace of the operations, and see if we can figure out how the >> installer's operations differ from the MMC operations. >> >> This will let us know if we can find a way the (presumably) subtly >> different operations take different code paths. >> >> Andrew Bartlett >> > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Another difference seems to be how it binds. I'm not sure what this
means, but the Client Name (Principal) part of the Kerberos ticket is different. Reminder - the modify performed by ADSI succeeds whereas the one by the installer fails. (Installer): Ticket Tkt-vno: 5 Realm: XMEN.ETI Server Name (Service and Instance): LDAP/samba01.xmen.eti enc-part rc4-hmac Encryption type: rc4-hmac (23) Kvno: 1 enc-part: 8640a4b3d70b45792896ad9add369caac8f37f5dd840cb84... [Decrypted using: keytab principal SAMBA01$@XMEN.ETI] EncTicketPart Padding: 0 Ticket Flags (Forwardable, Renewable, Pre-Auth, Transited Policy Checked, Ok As Delegate) key rc4-hmac Client Realm: XMEN.ETI Client Name (Principal): bhuffman-v1$ TransitedEncoding DOMAIN-X500-COMPRESS Authtime: 2012-07-30 13:05:38 (UTC) Start time: 2012-07-30 13:05:40 (UTC) End time: 2012-07-30 23:05:38 (UTC) Renew-till: 2012-08-06 13:05:38 (UTC) HostAddresses: BHUFFMAN-V1<20> AuthorizationData AD-IF-RELEVANT AuthorizationData AD-IF-RELEVANT AuthorizationData AD-IF-RELEVANT Authenticator rc4-hmac (ADSI): Ticket Tkt-vno: 5 Realm: XMEN.ETI Server Name (Service and Instance): ldap/samba01.xmen.eti enc-part rc4-hmac Encryption type: rc4-hmac (23) Kvno: 1 enc-part: 965665eeaffea85bad6bf33782bd99bf6a5b8eda0c12d0d4... [Decrypted using: keytab principal SAMBA01$@XMEN.ETI] EncTicketPart Padding: 0 Ticket Flags (Forwardable, Renewable, Pre-Auth, Transited Policy Checked, Ok As Delegate) key rc4-hmac Client Realm: XMEN.ETI Client Name (Principal): Administrator TransitedEncoding DOMAIN-X500-COMPRESS Authtime: 2012-07-30 13:25:52 (UTC) Start time: 2012-07-30 13:25:54 (UTC) End time: 2012-07-30 23:25:52 (UTC) Renew-till: 2012-08-06 13:25:52 (UTC) HostAddresses: BHUFFMAN-V1<20> AuthorizationData AD-IF-RELEVANT AuthorizationData AD-IF-RELEVANT AuthorizationData AD-IF-RELEVANT Authenticator rc4-hmac On 07/30/2012 11:20 AM, Nadezhda Ivanova wrote: > As far as I remember, there is no difference in access checks for > modify operations - add or replace, if there is WP access it should be > allowed. Can you check what are the permissions on > CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti? > > On Mon, Jul 30, 2012 at 5:45 PM, Brian C. Huffman > <[hidden email] <mailto:[hidden email]>> > wrote: > > Ok. I got the encryption figured out. > > So, there are two things that ADSI does differently: > > 1) It appears in wireshark that ADSI does two modify requests > (they look like duplicates to me, but I could be wrong). > > 2) ADSI does a "replace" whereas the installer does an "add" (the > 1st entry "1,{08...}" was already there) > (ADSI): > LDAPMessage modifyRequest(291) > "CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti" > messageID: 291 > protocolOp: modifyRequest (6) > modifyRequest > object: > CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > modification: 1 item > modification item > operation: replace (2) > modification adminContextMenu > type: adminContextMenu > vals: 2 items > 1,{08eb4fa6-6ffd-11d1-b0e0-00c04fd8dca6} > 2,{11330101-C4C8-11D6-B1DF-000476962053} > > (Installer): > LDAPMessage modifyRequest(25) > "CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti" > messageID: 25 > protocolOp: modifyRequest (6) > modifyRequest > object: > CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > modification: 1 item > modification item > operation: add (0) > modification adminContextMenu > type: adminContextMenu > vals: 1 item > 2,{11330101-C4C8-11D6-B1DF-000476962053} > > > -b > > > On 07/30/2012 09:47 AM, Brian C. Huffman wrote: > > I tried using a standard tcpdump -w and then loading the > result into wireshark, but the output for when I use ADSI > (MMC) is completely different and I don't see anything > recognizable there. In fact, wireshark doesn't even detect > the LDAP protcol at all - it's showing just TCP in the > protocol field for all packets. > > Might it be encrypted? If so, how would we go about finding a > useful trace to compare? > > Brian > > On 07/27/2012 08:55 PM, Andrew Bartlett wrote: > > On Fri, 2012-07-27 at 09:20 -0400, Brian C. Huffman wrote: > > Sorry - I should have been clear. I'm running as > "Administrator" which > is a member of the Enterprise Admins (and also Schema > Admins, just in case). > > If this is all being run as the same user, then the next > step is to get > a network trace of the operations, and see if we can > figure out how the > installer's operations differ from the MMC operations. > > This will let us know if we can find a way the > (presumably) subtly > different operations take different code paths. > > Andrew Bartlett > > > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
On Mon, 2012-07-30 at 14:05 -0400, Brian C. Huffman wrote:
> Another difference seems to be how it binds. I'm not sure what this > means, but the Client Name (Principal) part of the Kerberos ticket is > different. Reminder - the modify performed by ADSI succeeds whereas the > one by the installer fails. > > (Installer): > Client > Realm: XMEN.ETI > Client Name > (Principal): bhuffman-v1$ > (ADSI): > (Principal): Administrator This is the key detail. Install as administrator and it should just work. It is not generally expected that a machine account has permission to modify the directory. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Unfortunately I can run it as Administrator but it appears that
programatically it still tries to install as the machine account. I did some research and it turns out that the vendor intends you to run it on the AD server itself (which won't be possible for Samba). However while trying to work around this, I found a difference between Samba and a Windows 2008 AD server. With the Win2k8 AD server, I'm able to add the machine account, with inherited write permissions to CN=DisplaySpecifiers,CN=Configuration and then the installer succeeds. When I try to do the same with Samba, it doesn't give me any warnings, but it silently refuses to add the permissions to the descendants of DisplaySpecifiers. Is this known / intended behavior? Thanks, Brian On 07/31/2012 01:48 AM, Andrew Bartlett wrote: > On Mon, 2012-07-30 at 14:05 -0400, Brian C. Huffman wrote: >> Another difference seems to be how it binds. I'm not sure what this >> means, but the Client Name (Principal) part of the Kerberos ticket is >> different. Reminder - the modify performed by ADSI succeeds whereas the >> one by the installer fails. >> >> (Installer): >> Client >> Realm: XMEN.ETI >> Client Name >> (Principal): bhuffman-v1$ >> (ADSI): >> (Principal): Administrator > This is the key detail. Install as administrator and it should just > work. It is not generally expected that a machine account has > permission to modify the directory. > > Andrew Bartlett > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
It is known, but not intended, we have to fix the descriptor propagation.
On Tue, Jul 31, 2012 at 5:18 PM, Brian C. Huffman < [hidden email]> wrote: > Unfortunately I can run it as Administrator but it appears that > programatically it still tries to install as the machine account. I did > some research and it turns out that the vendor intends you to run it on the > AD server itself (which won't be possible for Samba). > > However while trying to work around this, I found a difference between > Samba and a Windows 2008 AD server. With the Win2k8 AD server, I'm able to > add the machine account, with inherited write permissions to > CN=DisplaySpecifiers,CN=**Configuration and then the installer succeeds. > When I try to do the same with Samba, it doesn't give me any warnings, but > it silently refuses to add the permissions to the descendants of > DisplaySpecifiers. Is this known / intended behavior? > > Thanks, > Brian > > > On 07/31/2012 01:48 AM, Andrew Bartlett wrote: > >> On Mon, 2012-07-30 at 14:05 -0400, Brian C. Huffman wrote: >> >>> Another difference seems to be how it binds. I'm not sure what this >>> means, but the Client Name (Principal) part of the Kerberos ticket is >>> different. Reminder - the modify performed by ADSI succeeds whereas the >>> one by the installer fails. >>> >>> (Installer): >>> Client >>> Realm: XMEN.ETI >>> Client Name >>> (Principal): bhuffman-v1$ >>> (ADSI): >>> (Principal): Administrator >>> >> This is the key detail. Install as administrator and it should just >> work. It is not generally expected that a machine account has >> permission to modify the directory. >> >> Andrew Bartlett >> >> > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
In reply to this post by Brian C. Huffman
On 07/31/2012 07:18 AM, Brian C. Huffman wrote:
> Unfortunately I can run it as Administrator but it appears that > programatically it still tries to install as the machine account. I > did some research and it turns out that the vendor intends you to run > it on the AD server itself (which won't be possible for Samba). > I suspect they expect you to run it on one of the DC, in this case the computer account is member of the domain controllers that have a lot of rights ! > However while trying to work around this, I found a difference between > Samba and a Windows 2008 AD server. With the Win2k8 AD server, I'm > able to add the machine account, with inherited write permissions to > CN=DisplaySpecifiers,CN=Configuration and then the installer > succeeds. When I try to do the same with Samba, it doesn't give me > any warnings, but it silently refuses to add the permissions to the > descendants of DisplaySpecifiers. Is this known / intended behavior? > As nadya said we now this "issue" the way to do it for you is to add the machine account via ADSI or ldbedit to the domain admins group, it should do the job. Once the installation is finished, remove it from this group. Matthieu. |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Matthieu,
I used the MMC "Active Directory Users and Computers" to make the change you suggested. Unfortunately I still get the insufficientAccessRights. So now I'm not sure what's going on because your idea made sense and sounded very promising. Brian On 07/31/2012 11:52 PM, Matthieu Patou wrote: > On 07/31/2012 07:18 AM, Brian C. Huffman wrote: >> Unfortunately I can run it as Administrator but it appears that >> programatically it still tries to install as the machine account. I >> did some research and it turns out that the vendor intends you to run >> it on the AD server itself (which won't be possible for Samba). >> > I suspect they expect you to run it on one of the DC, in this case the > computer account is member of the domain controllers that have a lot > of rights ! > >> However while trying to work around this, I found a difference >> between Samba and a Windows 2008 AD server. With the Win2k8 AD >> server, I'm able to add the machine account, with inherited write >> permissions to CN=DisplaySpecifiers,CN=Configuration and then the >> installer succeeds. When I try to do the same with Samba, it doesn't >> give me any warnings, but it silently refuses to add the permissions >> to the descendants of DisplaySpecifiers. Is this known / intended >> behavior? >> > As nadya said we now this "issue" the way to do it for you is to add > the machine account via ADSI or ldbedit to the domain admins group, it > should do the job. Once the installation is finished, remove it from > this group. > > Matthieu. > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Is it the same error on the same operation?
On Wed, Aug 1, 2012 at 4:49 PM, Brian C. Huffman < [hidden email]> wrote: > Matthieu, > > I used the MMC "Active Directory Users and Computers" to make the change > you suggested. Unfortunately I still get the insufficientAccessRights. So > now I'm not sure what's going on because your idea made sense and sounded > very promising. > > Brian > > > > > On 07/31/2012 11:52 PM, Matthieu Patou wrote: > >> On 07/31/2012 07:18 AM, Brian C. Huffman wrote: >> >>> Unfortunately I can run it as Administrator but it appears that >>> programatically it still tries to install as the machine account. I did >>> some research and it turns out that the vendor intends you to run it on the >>> AD server itself (which won't be possible for Samba). >>> >>> I suspect they expect you to run it on one of the DC, in this case the >> computer account is member of the domain controllers that have a lot of >> rights ! >> >> However while trying to work around this, I found a difference between >>> Samba and a Windows 2008 AD server. With the Win2k8 AD server, I'm able to >>> add the machine account, with inherited write permissions to >>> CN=DisplaySpecifiers,CN=**Configuration and then the installer >>> succeeds. When I try to do the same with Samba, it doesn't give me any >>> warnings, but it silently refuses to add the permissions to the descendants >>> of DisplaySpecifiers. Is this known / intended behavior? >>> >>> As nadya said we now this "issue" the way to do it for you is to add >> the machine account via ADSI or ldbedit to the domain admins group, it >> should do the job. Once the installation is finished, remove it from this >> group. >> >> Matthieu. >> >> >> > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Yep - In fact, I removed the machine account from Domain Admins, tried
again, and did a diff between the two modify responses. Kerberos info is different and the timestamps are different, but everything else is the same. Brian On 08/01/2012 09:51 AM, Nadezhda Ivanova wrote: > Is it the same error on the same operation? > > On Wed, Aug 1, 2012 at 4:49 PM, Brian C. Huffman > <[hidden email] <mailto:[hidden email]>> > wrote: > > Matthieu, > > I used the MMC "Active Directory Users and Computers" to make the > change you suggested. Unfortunately I still get the > insufficientAccessRights. So now I'm not sure what's going on > because your idea made sense and sounded very promising. > > Brian > > > > > On 07/31/2012 11:52 PM, Matthieu Patou wrote: > > On 07/31/2012 07:18 AM, Brian C. Huffman wrote: > > Unfortunately I can run it as Administrator but it appears > that programatically it still tries to install as the > machine account. I did some research and it turns out > that the vendor intends you to run it on the AD server > itself (which won't be possible for Samba). > > I suspect they expect you to run it on one of the DC, in this > case the computer account is member of the domain controllers > that have a lot of rights ! > > However while trying to work around this, I found a > difference between Samba and a Windows 2008 AD server. > With the Win2k8 AD server, I'm able to add the machine > account, with inherited write permissions to > CN=DisplaySpecifiers,CN=Configuration and then the > installer succeeds. When I try to do the same with Samba, > it doesn't give me any warnings, but it silently refuses > to add the permissions to the descendants of > DisplaySpecifiers. Is this known / intended behavior? > > As nadya said we now this "issue" the way to do it for you is > to add the machine account via ADSI or ldbedit to the domain > admins group, it should do the job. Once the installation is > finished, remove it from this group. > > Matthieu. > > > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Hi Brian,
We will need to take a look at the access check dumps. To do that, you need to run Samba with log level 10. Add the machine account to the Domain Admin groups, and repeat the installation. The log file will be enormous, but search for something like: Object CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti has no write property access Access on CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti denied After that there should be a dump of the security token, which looks something like this: Security context: : struct security_token user_sid : * user_sid : S-1-5-21-2851635801-3495335766-3134857892-1014 group_sid : * group_sid : S-1-5-21-2851635801-3495335766-3134857892-513 num_sids : 0x00000006 (6) sids: ARRAY(6) sids : * sids : S-1-5-21-2851635801-3495335766-3134857892-1014 sids : * sids : S-1-5-21-2851635801-3495335766-3134857892-513 sids : * sids : S-1-1-0 sids : * sids : S-1-5-2 sids : * sids : S-1-5-11 sids : * sids : S-1-5-32-545 privilege_mask : 0x0000000000000000 (0) and after that is a dump of the security descriptor for the object. It can be very big, starts with something like: Security descriptor: : struct security_descriptor revision : SECURITY_DESCRIPTOR_REVISION_1 (1) type : 0x8c14 (35860) 0: SEC_DESC_OWNER_DEFAULTED 0: SEC_DESC_GROUP_DEFAULTED 1: SEC_DESC_DACL_PRESENT 0: SEC_DESC_DACL_DEFAULTED 1: SEC_DESC_SACL_PRESENT 0: SEC_DESC_SACL_DEFAULTED 0: SEC_DESC_DACL_TRUSTED 0: SEC_DESC_SERVER_SECURITY 0: SEC_DESC_DACL_AUTO_INHERIT_REQ 0: SEC_DESC_SACL_AUTO_INHERIT_REQ 1: SEC_DESC_DACL_AUTO_INHERITED 1: SEC_DESC_SACL_AUTO_INHERITED 0: SEC_DESC_DACL_PROTECTED 0: SEC_DESC_SACL_PROTECTED 0: SEC_DESC_RM_CONTROL_VALID 1: SEC_DESC_SELF_RELATIVE And goes on with the list of all ACEs in sacl and dacl. We will need all that to figure out why the access checks have failed, could you send it? Regards, Nadya On Wed, Aug 1, 2012 at 5:01 PM, Brian C. Huffman < [hidden email]> wrote: > Yep - In fact, I removed the machine account from Domain Admins, tried > again, and did a diff between the two modify responses. Kerberos info is > different and the timestamps are different, but everything else is the same. > > Brian > > > On 08/01/2012 09:51 AM, Nadezhda Ivanova wrote: > > Is it the same error on the same operation? > > On Wed, Aug 1, 2012 at 4:49 PM, Brian C. Huffman < > [hidden email]> wrote: > >> Matthieu, >> >> I used the MMC "Active Directory Users and Computers" to make the change >> you suggested. Unfortunately I still get the insufficientAccessRights. So >> now I'm not sure what's going on because your idea made sense and sounded >> very promising. >> >> Brian >> >> >> >> >> On 07/31/2012 11:52 PM, Matthieu Patou wrote: >> >>> On 07/31/2012 07:18 AM, Brian C. Huffman wrote: >>> >>>> Unfortunately I can run it as Administrator but it appears that >>>> programatically it still tries to install as the machine account. I did >>>> some research and it turns out that the vendor intends you to run it on the >>>> AD server itself (which won't be possible for Samba). >>>> >>>> I suspect they expect you to run it on one of the DC, in this case the >>> computer account is member of the domain controllers that have a lot of >>> rights ! >>> >>> However while trying to work around this, I found a difference between >>>> Samba and a Windows 2008 AD server. With the Win2k8 AD server, I'm able to >>>> add the machine account, with inherited write permissions to >>>> CN=DisplaySpecifiers,CN=Configuration and then the installer succeeds. >>>> When I try to do the same with Samba, it doesn't give me any warnings, but >>>> it silently refuses to add the permissions to the descendants of >>>> DisplaySpecifiers. Is this known / intended behavior? >>>> >>>> As nadya said we now this "issue" the way to do it for you is to add >>> the machine account via ADSI or ldbedit to the domain admins group, it >>> should do the job. Once the installation is finished, remove it from this >>> group. >>> >>> Matthieu. >>> >>> >>> >> > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
Here you go:
[2012/08/01 14:35:39, 10, pid=15547, effective(0, 0), real(0, 0)] ../source4/dsdb/common/dsdb_access.c:47(dsdb_acl_debug) Access on CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti deniedSecurity context: : struct security_token num_sids : 0x00000005 (5) sids: ARRAY(5) sids : S-1-5-21-2824053618-3522172672-2706769870-1104 sids : S-1-5-21-2824053618-3522172672-2706769870-515 sids : S-1-1-0 sids : S-1-5-2 sids : S-1-5-11 privilege_mask : 0x0000000000000000 (0) 0: SEC_PRIV_MACHINE_ACCOUNT_BIT 0: SEC_PRIV_PRINT_OPERATOR_BIT 0: SEC_PRIV_ADD_USERS_BIT 0: SEC_PRIV_DISK_OPERATOR_BIT 0: SEC_PRIV_REMOTE_SHUTDOWN_BIT 0: SEC_PRIV_BACKUP_BIT 0: SEC_PRIV_RESTORE_BIT 0: SEC_PRIV_TAKE_OWNERSHIP_BIT 0: SEC_PRIV_INCREASE_QUOTA_BIT 0: SEC_PRIV_SECURITY_BIT 0: SEC_PRIV_LOAD_DRIVER_BIT 0: SEC_PRIV_SYSTEM_PROFILE_BIT 0: SEC_PRIV_SYSTEMTIME_BIT 0: SEC_PRIV_PROFILE_SINGLE_PROCESS_BIT 0: SEC_PRIV_INCREASE_BASE_PRIORITY_BIT 0: SEC_PRIV_CREATE_PAGEFILE_BIT 0: SEC_PRIV_SHUTDOWN_BIT 0: SEC_PRIV_DEBUG_BIT 0: SEC_PRIV_SYSTEM_ENVIRONMENT_BIT 0: SEC_PRIV_CHANGE_NOTIFY_BIT 0: SEC_PRIV_UNDOCK_BIT 0: SEC_PRIV_ENABLE_DELEGATION_BIT 0: SEC_PRIV_MANAGE_VOLUME_BIT 0: SEC_PRIV_IMPERSONATE_BIT 0: SEC_PRIV_CREATE_GLOBAL_BIT rights_mask : 0x00000000 (0) 0: LSA_POLICY_MODE_INTERACTIVE 0: LSA_POLICY_MODE_NETWORK 0: LSA_POLICY_MODE_BATCH 0: LSA_POLICY_MODE_SERVICE 0: LSA_POLICY_MODE_PROXY 0: LSA_POLICY_MODE_DENY_INTERACTIVE 0: LSA_POLICY_MODE_DENY_NETWORK 0: LSA_POLICY_MODE_DENY_BATCH 0: LSA_POLICY_MODE_DENY_SERVICE 0: LSA_POLICY_MODE_REMOTE_INTERACTIVE 0: LSA_POLICY_MODE_DENY_REMOTE_INTERACTIVE 0x00: LSA_POLICY_MODE_ALL (0) 0x00: LSA_POLICY_MODE_ALL_NT4 (0) [2012/08/01 14:35:39, 10, pid=15547, effective(0, 0), real(0, 0)] ../source4/dsdb/common/dsdb_access.c:55(dsdb_acl_debug) Security descriptor: : struct security_descriptor revision : SECURITY_DESCRIPTOR_REVISION_1 (1) type : 0x8405 (33797) 1: SEC_DESC_OWNER_DEFAULTED 0: SEC_DESC_GROUP_DEFAULTED 1: SEC_DESC_DACL_PRESENT 0: SEC_DESC_DACL_DEFAULTED 0: SEC_DESC_SACL_PRESENT 0: SEC_DESC_SACL_DEFAULTED 0: SEC_DESC_DACL_TRUSTED 0: SEC_DESC_SERVER_SECURITY 0: SEC_DESC_DACL_AUTO_INHERIT_REQ 0: SEC_DESC_SACL_AUTO_INHERIT_REQ 1: SEC_DESC_DACL_AUTO_INHERITED 0: SEC_DESC_SACL_AUTO_INHERITED 0: SEC_DESC_DACL_PROTECTED 0: SEC_DESC_SACL_PROTECTED 0: SEC_DESC_RM_CONTROL_VALID 1: SEC_DESC_SELF_RELATIVE owner_sid : * owner_sid : S-1-5-21-2824053618-3522172672-2706769870-519 group_sid : * group_sid : S-1-5-21-2824053618-3522172672-2706769870-513 sacl : NULL dacl : * dacl: struct security_acl revision : SECURITY_ACL_REVISION_ADS (4) size : 0x009c (156) num_aces : 0x00000005 (5) aces: ARRAY(5) aces: struct security_ace type : SEC_ACE_TYPE_ACCESS_ALLOWED (0) flags : 0x00 (0) 0: SEC_ACE_FLAG_OBJECT_INHERIT 0: SEC_ACE_FLAG_CONTAINER_INHERIT 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT 0: SEC_ACE_FLAG_INHERIT_ONLY 0: SEC_ACE_FLAG_INHERITED_ACE 0x00: SEC_ACE_FLAG_VALID_INHERIT (0) 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS 0: SEC_ACE_FLAG_FAILED_ACCESS size : 0x0024 (36) access_mask : 0x000f01ff (983551) object : union security_ace_object_ctr(case 0) trustee : S-1-5-21-2824053618-3522172672-2706769870-512 aces: struct security_ace type : SEC_ACE_TYPE_ACCESS_ALLOWED (0) flags : 0x00 (0) 0: SEC_ACE_FLAG_OBJECT_INHERIT 0: SEC_ACE_FLAG_CONTAINER_INHERIT 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT 0: SEC_ACE_FLAG_INHERIT_ONLY 0: SEC_ACE_FLAG_INHERITED_ACE 0x00: SEC_ACE_FLAG_VALID_INHERIT (0) 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS 0: SEC_ACE_FLAG_FAILED_ACCESS size : 0x0014 (20) access_mask : 0x000f01ff (983551) object : union security_ace_object_ctr(case 0) trustee : S-1-5-18 aces: struct security_ace type : SEC_ACE_TYPE_ACCESS_ALLOWED (0) flags : 0x00 (0) 0: SEC_ACE_FLAG_OBJECT_INHERIT 0: SEC_ACE_FLAG_CONTAINER_INHERIT 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT 0: SEC_ACE_FLAG_INHERIT_ONLY 0: SEC_ACE_FLAG_INHERITED_ACE 0x00: SEC_ACE_FLAG_VALID_INHERIT (0) 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS 0: SEC_ACE_FLAG_FAILED_ACCESS size : 0x0014 (20) access_mask : 0x00020094 (131220) object : union security_ace_object_ctr(case 0) trustee : S-1-5-11 aces: struct security_ace type : SEC_ACE_TYPE_ACCESS_ALLOWED (0) flags : 0x12 (18) 0: SEC_ACE_FLAG_OBJECT_INHERIT 1: SEC_ACE_FLAG_CONTAINER_INHERIT 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT 0: SEC_ACE_FLAG_INHERIT_ONLY 1: SEC_ACE_FLAG_INHERITED_ACE 0x02: SEC_ACE_FLAG_VALID_INHERIT (2) 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS 0: SEC_ACE_FLAG_FAILED_ACCESS size : 0x0024 (36) access_mask : 0x000f01ff (983551) object : union security_ace_object_ctr(case 0) trustee : S-1-5-21-2824053618-3522172672-2706769870-519 aces: struct security_ace type : SEC_ACE_TYPE_ACCESS_ALLOWED (0) flags : 0x12 (18) 0: SEC_ACE_FLAG_OBJECT_INHERIT 1: SEC_ACE_FLAG_CONTAINER_INHERIT 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT 0: SEC_ACE_FLAG_INHERIT_ONLY 1: SEC_ACE_FLAG_INHERITED_ACE 0x02: SEC_ACE_FLAG_VALID_INHERIT (2) 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS 0: SEC_ACE_FLAG_FAILED_ACCESS size : 0x0024 (36) access_mask : 0x000f01bd (983485) object : union security_ace_object_ctr(case 0) trustee : S-1-5-21-2824053618-3522172672-2706769870-512 [2012/08/01 14:35:39, 5, pid=15547, effective(0, 0), real(0, 0)] ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug) ldb: cancel ldb transaction (nesting: 0) Let me know if you need anything additional. Thanks! Brian On 08/01/2012 02:02 PM, Nadezhda Ivanova wrote: > Hi Brian, > We will need to take a look at the access check dumps. To do that, you > need to run Samba with log level 10. Add the machine account to the > Domain Admin groups, and repeat the installation. The log file will be > enormous, but search for something like: > Object > CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > has no write property access > Access on > CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > denied > > After that there should be a dump of the security token, which looks > something like this: > Security context: : struct security_token > user_sid : * > user_sid : > S-1-5-21-2851635801-3495335766-3134857892-1014 > group_sid : * > group_sid : > S-1-5-21-2851635801-3495335766-3134857892-513 > num_sids : 0x00000006 (6) > sids: ARRAY(6) > sids : * > sids : > S-1-5-21-2851635801-3495335766-3134857892-1014 > sids : * > sids : > S-1-5-21-2851635801-3495335766-3134857892-513 > sids : * > sids : S-1-1-0 > sids : * > sids : S-1-5-2 > sids : * > sids : S-1-5-11 > sids : * > sids : S-1-5-32-545 > privilege_mask : 0x0000000000000000 (0) > > and after that is a dump of the security descriptor for the object. It > can be very big, starts with something like: > Security descriptor: : struct security_descriptor > revision : SECURITY_DESCRIPTOR_REVISION_1 (1) > type : 0x8c14 (35860) > 0: SEC_DESC_OWNER_DEFAULTED > 0: SEC_DESC_GROUP_DEFAULTED > 1: SEC_DESC_DACL_PRESENT > 0: SEC_DESC_DACL_DEFAULTED > 1: SEC_DESC_SACL_PRESENT > 0: SEC_DESC_SACL_DEFAULTED > 0: SEC_DESC_DACL_TRUSTED > 0: SEC_DESC_SERVER_SECURITY > 0: SEC_DESC_DACL_AUTO_INHERIT_REQ > 0: SEC_DESC_SACL_AUTO_INHERIT_REQ > 1: SEC_DESC_DACL_AUTO_INHERITED > 1: SEC_DESC_SACL_AUTO_INHERITED > 0: SEC_DESC_DACL_PROTECTED > 0: SEC_DESC_SACL_PROTECTED > 0: SEC_DESC_RM_CONTROL_VALID > 1: SEC_DESC_SELF_RELATIVE > > > And goes on with the list of all ACEs in sacl and dacl. We will need > all that to figure out why the access checks have failed, could you > send it? > > Regards, > Nadya > > > On Wed, Aug 1, 2012 at 5:01 PM, Brian C. Huffman > <[hidden email] <mailto:[hidden email]>> > wrote: > > Yep - In fact, I removed the machine account from Domain Admins, > tried again, and did a diff between the two modify responses. > Kerberos info is different and the timestamps are different, but > everything else is the same. > > Brian > > > On 08/01/2012 09:51 AM, Nadezhda Ivanova wrote: >> Is it the same error on the same operation? >> >> On Wed, Aug 1, 2012 at 4:49 PM, Brian C. Huffman >> <[hidden email] >> <mailto:[hidden email]>> wrote: >> >> Matthieu, >> >> I used the MMC "Active Directory Users and Computers" to make >> the change you suggested. Unfortunately I still get the >> insufficientAccessRights. So now I'm not sure what's going >> on because your idea made sense and sounded very promising. >> >> Brian >> >> >> >> >> On 07/31/2012 11:52 PM, Matthieu Patou wrote: >> >> On 07/31/2012 07:18 AM, Brian C. Huffman wrote: >> >> Unfortunately I can run it as Administrator but it >> appears that programatically it still tries to >> install as the machine account. I did some research >> and it turns out that the vendor intends you to run >> it on the AD server itself (which won't be possible >> for Samba). >> >> I suspect they expect you to run it on one of the DC, in >> this case the computer account is member of the domain >> controllers that have a lot of rights ! >> >> However while trying to work around this, I found a >> difference between Samba and a Windows 2008 AD >> server. With the Win2k8 AD server, I'm able to add >> the machine account, with inherited write permissions >> to CN=DisplaySpecifiers,CN=Configuration and then the >> installer succeeds. When I try to do the same with >> Samba, it doesn't give me any warnings, but it >> silently refuses to add the permissions to the >> descendants of DisplaySpecifiers. Is this known / >> intended behavior? >> >> As nadya said we now this "issue" the way to do it for >> you is to add the machine account via ADSI or ldbedit to >> the domain admins group, it should do the job. Once the >> installation is finished, remove it from this group. >> >> Matthieu. >> >> >> >> > > |
Re: Samba 4 insufficientAccessRights when modifying Configuration
|
|
From the security token it is seen that the user is not a member of Domain
admins or enterprise admins. All we have is: sids : S-1-5-21-2824053618-3522172672-2706769870-1104 - I assume this is the machine account sid sids : S-1-5-21-2824053618-3522172672-2706769870-515 - Domain Computers sids : S-1-1-0 - Everyone sids : S-1-5-2 - Network sids : S-1-5-11 - Authenticated Users For some reason the account has not become a member of Domain Admins. On Wed, Aug 1, 2012 at 9:56 PM, Brian C. Huffman < [hidden email]> wrote: > Here you go: > [2012/08/01 14:35:39, 10, pid=15547, effective(0, 0), real(0, 0)] > ../source4/dsdb/common/dsdb_access.c:47(dsdb_acl_debug) > Access on > CN=user-Display,CN=C0A,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > deniedSecurity context: : struct security_token > num_sids : 0x00000005 (5) > sids: ARRAY(5) > sids : > S-1-5-21-2824053618-3522172672-2706769870-1104 > sids : > S-1-5-21-2824053618-3522172672-2706769870-515 > sids : S-1-1-0 > sids : S-1-5-2 > sids : S-1-5-11 > privilege_mask : 0x0000000000000000 (0) > 0: SEC_PRIV_MACHINE_ACCOUNT_BIT > 0: SEC_PRIV_PRINT_OPERATOR_BIT > 0: SEC_PRIV_ADD_USERS_BIT > 0: SEC_PRIV_DISK_OPERATOR_BIT > 0: SEC_PRIV_REMOTE_SHUTDOWN_BIT > 0: SEC_PRIV_BACKUP_BIT > 0: SEC_PRIV_RESTORE_BIT > 0: SEC_PRIV_TAKE_OWNERSHIP_BIT > 0: SEC_PRIV_INCREASE_QUOTA_BIT > 0: SEC_PRIV_SECURITY_BIT > 0: SEC_PRIV_LOAD_DRIVER_BIT > 0: SEC_PRIV_SYSTEM_PROFILE_BIT > 0: SEC_PRIV_SYSTEMTIME_BIT > 0: SEC_PRIV_PROFILE_SINGLE_PROCESS_BIT > 0: SEC_PRIV_INCREASE_BASE_PRIORITY_BIT > 0: SEC_PRIV_CREATE_PAGEFILE_BIT > 0: SEC_PRIV_SHUTDOWN_BIT > 0: SEC_PRIV_DEBUG_BIT > 0: SEC_PRIV_SYSTEM_ENVIRONMENT_BIT > 0: SEC_PRIV_CHANGE_NOTIFY_BIT > 0: SEC_PRIV_UNDOCK_BIT > 0: SEC_PRIV_ENABLE_DELEGATION_BIT > 0: SEC_PRIV_MANAGE_VOLUME_BIT > 0: SEC_PRIV_IMPERSONATE_BIT > 0: SEC_PRIV_CREATE_GLOBAL_BIT > rights_mask : 0x00000000 (0) > 0: LSA_POLICY_MODE_INTERACTIVE > 0: LSA_POLICY_MODE_NETWORK > 0: LSA_POLICY_MODE_BATCH > 0: LSA_POLICY_MODE_SERVICE > 0: LSA_POLICY_MODE_PROXY > 0: LSA_POLICY_MODE_DENY_INTERACTIVE > 0: LSA_POLICY_MODE_DENY_NETWORK > 0: LSA_POLICY_MODE_DENY_BATCH > 0: LSA_POLICY_MODE_DENY_SERVICE > 0: LSA_POLICY_MODE_REMOTE_INTERACTIVE > 0: LSA_POLICY_MODE_DENY_REMOTE_INTERACTIVE > 0x00: LSA_POLICY_MODE_ALL (0) > 0x00: LSA_POLICY_MODE_ALL_NT4 (0) > > [2012/08/01 14:35:39, 10, pid=15547, effective(0, 0), real(0, 0)] > ../source4/dsdb/common/dsdb_access.c:55(dsdb_acl_debug) > > Security descriptor: : struct security_descriptor > revision : SECURITY_DESCRIPTOR_REVISION_1 (1) > type : 0x8405 (33797) > > 1: SEC_DESC_OWNER_DEFAULTED > 0: SEC_DESC_GROUP_DEFAULTED > 1: SEC_DESC_DACL_PRESENT > 0: SEC_DESC_DACL_DEFAULTED > 0: SEC_DESC_SACL_PRESENT > 0: SEC_DESC_SACL_DEFAULTED > 0: SEC_DESC_DACL_TRUSTED > 0: SEC_DESC_SERVER_SECURITY > 0: SEC_DESC_DACL_AUTO_INHERIT_REQ > 0: SEC_DESC_SACL_AUTO_INHERIT_REQ > 1: SEC_DESC_DACL_AUTO_INHERITED > 0: SEC_DESC_SACL_AUTO_INHERITED > 0: SEC_DESC_DACL_PROTECTED > 0: SEC_DESC_SACL_PROTECTED > 0: SEC_DESC_RM_CONTROL_VALID > 1: SEC_DESC_SELF_RELATIVE > owner_sid : * > owner_sid : > S-1-5-21-2824053618-3522172672-2706769870-519 > group_sid : * > group_sid : > S-1-5-21-2824053618-3522172672-2706769870-513 > sacl : NULL > dacl : * > dacl: struct security_acl > revision : SECURITY_ACL_REVISION_ADS (4) > size : 0x009c (156) > num_aces : 0x00000005 (5) > aces: ARRAY(5) > aces: struct security_ace > type : > SEC_ACE_TYPE_ACCESS_ALLOWED (0) > flags : 0x00 (0) > 0: SEC_ACE_FLAG_OBJECT_INHERIT > 0: SEC_ACE_FLAG_CONTAINER_INHERIT > 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT > 0: SEC_ACE_FLAG_INHERIT_ONLY > 0: SEC_ACE_FLAG_INHERITED_ACE > 0x00: SEC_ACE_FLAG_VALID_INHERIT (0) > 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS > 0: SEC_ACE_FLAG_FAILED_ACCESS > size : 0x0024 (36) > access_mask : 0x000f01ff (983551) > object : union > security_ace_object_ctr(case 0) > trustee : > S-1-5-21-2824053618-3522172672-2706769870-512 > aces: struct security_ace > type : > SEC_ACE_TYPE_ACCESS_ALLOWED (0) > flags : 0x00 (0) > 0: SEC_ACE_FLAG_OBJECT_INHERIT > 0: SEC_ACE_FLAG_CONTAINER_INHERIT > 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT > 0: SEC_ACE_FLAG_INHERIT_ONLY > 0: SEC_ACE_FLAG_INHERITED_ACE > 0x00: SEC_ACE_FLAG_VALID_INHERIT (0) > 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS > 0: SEC_ACE_FLAG_FAILED_ACCESS > size : 0x0014 (20) > access_mask : 0x000f01ff (983551) > object : union > security_ace_object_ctr(case 0) > trustee : S-1-5-18 > aces: struct security_ace > type : > SEC_ACE_TYPE_ACCESS_ALLOWED (0) > flags : 0x00 (0) > 0: SEC_ACE_FLAG_OBJECT_INHERIT > 0: SEC_ACE_FLAG_CONTAINER_INHERIT > 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT > 0: SEC_ACE_FLAG_INHERIT_ONLY > 0: SEC_ACE_FLAG_INHERITED_ACE > 0x00: SEC_ACE_FLAG_VALID_INHERIT (0) > 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS > 0: SEC_ACE_FLAG_FAILED_ACCESS > size : 0x0014 (20) > access_mask : 0x00020094 (131220) > object : union > security_ace_object_ctr(case 0) > trustee : S-1-5-11 > aces: struct security_ace > type : > SEC_ACE_TYPE_ACCESS_ALLOWED (0) > flags : 0x12 (18) > 0: SEC_ACE_FLAG_OBJECT_INHERIT > 1: SEC_ACE_FLAG_CONTAINER_INHERIT > 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT > 0: SEC_ACE_FLAG_INHERIT_ONLY > 1: SEC_ACE_FLAG_INHERITED_ACE > 0x02: SEC_ACE_FLAG_VALID_INHERIT (2) > 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS > 0: SEC_ACE_FLAG_FAILED_ACCESS > size : 0x0024 (36) > access_mask : 0x000f01ff (983551) > object : union > security_ace_object_ctr(case 0) > trustee : > S-1-5-21-2824053618-3522172672-2706769870-519 > aces: struct security_ace > type : > SEC_ACE_TYPE_ACCESS_ALLOWED (0) > flags : 0x12 (18) > 0: SEC_ACE_FLAG_OBJECT_INHERIT > 1: SEC_ACE_FLAG_CONTAINER_INHERIT > 0: SEC_ACE_FLAG_NO_PROPAGATE_INHERIT > 0: SEC_ACE_FLAG_INHERIT_ONLY > 1: SEC_ACE_FLAG_INHERITED_ACE > 0x02: SEC_ACE_FLAG_VALID_INHERIT (2) > 0: SEC_ACE_FLAG_SUCCESSFUL_ACCESS > 0: SEC_ACE_FLAG_FAILED_ACCESS > size : 0x0024 (36) > access_mask : 0x000f01bd (983485) > object : union > security_ace_object_ctr(case 0) > trustee : > S-1-5-21-2824053618-3522172672-2706769870-512 > > [2012/08/01 14:35:39, 5, pid=15547, effective(0, 0), real(0, 0)] > ../lib/ldb-samba/ldb_wrap.c:68(ldb_wrap_debug) > ldb: cancel ldb transaction (nesting: 0) > > Let me know if you need anything additional. > > Thanks! > Brian > > > On 08/01/2012 02:02 PM, Nadezhda Ivanova wrote: > > Hi Brian, > We will need to take a look at the access check dumps. To do that, you > need to run Samba with log level 10. Add the machine account to the Domain > Admin groups, and repeat the installation. The log file will be enormous, > but search for something like: > Object > CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > has no write property access > Access on > CN=group-Display,CN=407,CN=DisplaySpecifiers,CN=Configuration,DC=xmen,DC=eti > denied > > After that there should be a dump of the security token, which looks > something like this: > Security context: : struct security_token > user_sid : * > user_sid : > S-1-5-21-2851635801-3495335766-3134857892-1014 > group_sid : * > group_sid : > S-1-5-21-2851635801-3495335766-3134857892-513 > num_sids : 0x00000006 (6) > sids: ARRAY(6) > sids : * > sids : > S-1-5-21-2851635801-3495335766-3134857892-1014 > sids : * > sids : > S-1-5-21-2851635801-3495335766-3134857892-513 > sids : * > sids : S-1-1-0 > sids : * > sids : S-1-5-2 > sids : * > sids : S-1-5-11 > sids : * > sids : S-1-5-32-545 > privilege_mask : 0x0000000000000000 (0) > > and after that is a dump of the security descriptor for the object. It can > be very big, starts with something like: > Security descriptor: : struct security_descriptor > revision : SECURITY_DESCRIPTOR_REVISION_1 (1) > type : 0x8c14 (35860) > 0: SEC_DESC_OWNER_DEFAULTED > 0: SEC_DESC_GROUP_DEFAULTED > 1: SEC_DESC_DACL_PRESENT > 0: SEC_DESC_DACL_DEFAULTED > 1: SEC_DESC_SACL_PRESENT > 0: SEC_DESC_SACL_DEFAULTED > 0: SEC_DESC_DACL_TRUSTED > 0: SEC_DESC_SERVER_SECURITY > 0: SEC_DESC_DACL_AUTO_INHERIT_REQ > 0: SEC_DESC_SACL_AUTO_INHERIT_REQ > 1: SEC_DESC_DACL_AUTO_INHERITED > 1: SEC_DESC_SACL_AUTO_INHERITED > 0: SEC_DESC_DACL_PROTECTED > 0: SEC_DESC_SACL_PROTECTED > 0: SEC_DESC_RM_CONTROL_VALID > 1: SEC_DESC_SELF_RELATIVE > > > And goes on with the list of all ACEs in sacl and dacl. We will need all > that to figure out why the access checks have failed, could you send it? > > Regards, > Nadya > > > On Wed, Aug 1, 2012 at 5:01 PM, Brian C. Huffman < > [hidden email]> wrote: > >> Yep - In fact, I removed the machine account from Domain Admins, tried >> again, and did a diff between the two modify responses. Kerberos info is >> different and the timestamps are different, but everything else is the same. >> >> Brian >> >> >> On 08/01/2012 09:51 AM, Nadezhda Ivanova wrote: >> >> Is it the same error on the same operation? >> >> On Wed, Aug 1, 2012 at 4:49 PM, Brian C. Huffman < >> [hidden email]> wrote: >> >>> Matthieu, >>> >>> I used the MMC "Active Directory Users and Computers" to make the change >>> you suggested. Unfortunately I still get the insufficientAccessRights. So >>> now I'm not sure what's going on because your idea made sense and sounded >>> very promising. >>> >>> Brian >>> >>> >>> >>> >>> On 07/31/2012 11:52 PM, Matthieu Patou wrote: >>> >>>> On 07/31/2012 07:18 AM, Brian C. Huffman wrote: >>>> >>>>> Unfortunately I can run it as Administrator but it appears that >>>>> programatically it still tries to install as the machine account. I did >>>>> some research and it turns out that the vendor intends you to run it on the >>>>> AD server itself (which won't be possible for Samba). >>>>> >>>>> I suspect they expect you to run it on one of the DC, in this case >>>> the computer account is member of the domain controllers that have a lot of >>>> rights ! >>>> >>>> However while trying to work around this, I found a difference between >>>>> Samba and a Windows 2008 AD server. With the Win2k8 AD server, I'm able to >>>>> add the machine account, with inherited write permissions to >>>>> CN=DisplaySpecifiers,CN=Configuration and then the installer succeeds. >>>>> When I try to do the same with Samba, it doesn't give me any warnings, but >>>>> it silently refuses to add the permissions to the descendants of >>>>> DisplaySpecifiers. Is this known / intended behavior? >>>>> >>>>> As nadya said we now this "issue" the way to do it for you is to add >>>> the machine account via ADSI or ldbedit to the domain admins group, it >>>> should do the job. Once the installation is finished, remove it from this >>>> group. >>>> >>>> Matthieu. >>>> >>>> >>>> >>> >> >> > > |
«
Return to Samba - samba-technical
|
1 view|%1 views
Loading...
| Powered by Nabble | Edit this page |