Using the git commit from 2013.05.05 (5f82641553), I see a lot of this error in the samba log: [2013/05/03 11:55:41, 0] ../source4/rpc_server/drsuapi/writespn.c:237(dcesrv_drsuapi_DsWriteAccountSpn) Failed to modify SPNs on CN=AIO6,CN=Computers,DC=corp,DC=example,DC=com: error in module acl: insufficient access rights (50) [2013/05/03 11:55:42, 0] ../source4/rpc_server/drsuapi/writespn.c:237(dcesrv_drsuapi_DsWriteAccountSpn) Failed to modify SPNs on CN=AIO6,CN=Computers,DC=corp,DC=example,DC=com: error in module acl: insufficient access rights (50) It's only occurring on this single machine (CN=AIO6), and none of the other ~15 identical machines. Happy to provided any needed debug info.
FYI, I'm still seeing this, with today's latest GIT build (4.2.0pre1-GIT-0045f3b), with all Windows 8.1 clients. The error has evolved a tiny bit, and is now: samba[2163]: [2014/01/10 09:31:05.484968, 0] ../source4/rpc_server/drsuapi/writespn.c:237(dcesrv_drsuapi_DsWriteAccountSpn) samba[2163]: Failed to modify SPNs on CN=AIO6,CN=Computers,DC=corp,DC=aldinetravel,DC=com: error in module acl: insufficient access rights during LDB_MODIFY (50) Any thoughts on tracking this down? It's again only a single machine "AIO6" -- a number of other identical machines don't show this message.
Maybe related to https://bugzilla.samba.org/show_bug.cgi?id=9316 Failed to modify SPNs on ...: error in module acl: Constraint violation (19)
Just updating, since this is marked as a 4.2 blocker. I still see this issue as of ~yesterday's head: commit 71cb5749f4d7a542a1dccb250f91c58fd2bbf54c Author: Stefan Metzmacher <metze@samba.org> Date: Tue Oct 7 15:59:48 2014 +0200 libcli/smb: try to negotiate SMB2_ENCRYPTION_AES128_GCM It seems to occur intermittently, referring to a few client machines. Oct 17 09:53:45 runway samba[13224]: Failed to modify SPNs on CN=AIO3,CN=Computers,DC=corp,DC=mydomainhere,DC=com: error in module acl: insufficient access rights during LDB_MODIFY (50)
Nadya, could you look into this?
Hi Nick, Is it possible for you to run samba with debug level 10 and attach the log (assuming it's OK to share such data publicly). Level 10 has a debug log of the access check process, it dumps the security descriptor on the modified object and the security token of the account used to modify it. It's going to be quite a big log file...
FWIW, haven't seen this issue in recent logs -- may have been fixed in git at some point. Since I was the only one reporting it, closing for now.
I also saw this more than once...