Samba 4 insufficientAccessRights when modifying Configuration
Brian C. Huffman
bhuffman at etinternational.com
Mon Jul 30 12:05:55 MDT 2012
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
> <bhuffman at etinternational.com <mailto:bhuffman at etinternational.com>>
> 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
>
>
>
>
More information about the samba-technical
mailing list