Bug 7114 - Permissive Modify fails
Summary: Permissive Modify fails
Alias: None
Product: Samba 4.0
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: unspecified
Hardware: Other FreeBSD
: P3 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: samba4-qa@samba.org
Depends on:
Reported: 2010-02-08 03:45 UTC by Christoph Theis
Modified: 2010-02-22 16:04 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Theis 2010-02-08 03:45:47 UTC
I have a Samba 4 (alpha 11) server acting as an AD and a Samba 3
client as a domain client, both runing under FreeBSD. To add an SPN
for the client I run the command "net ads keytab add HTTP". There is
no output but "net ads keytab list" does not show that SPN. Sniffing
the network traffic I see that the client uses the control
LDAP_SERVER_PERMISSIVE_MODIFY_OID with the critical-bit set and the
server responds with an error "Unsupported critical extension".

I could reproduce the behaviour by running ldbmodify on the server:

ldbmodify -H ldap://servername -k 1 --controls=permissive_modify:1 test

with the file content of test

dn: CN=workstation,CN=Computers,DC=EXAMPLE,DC=ORG
changetype: modify
add: servicePrincipalName
servicePrincipalName: HTTP/workstation

When I set the critical bit to 0 the call succeeds. When I run it
again I get an error "Attribute or value exists". In my understanding
this is wrong, permissive modify shall not return an error when the
attribute with the same value already exists or when an attribute to
be deleted does not exists.

The call "net ads join" makes the same calls and thus is not able to create the required SPNs.
Comment 2 Christoph Theis 2010-02-17 13:54:40 UTC
(In reply to comment #1)
> Thanks for reporting this. If the problem still persists, please reopen!

It's still not working for me, I still get the "Unsupported critical extension" error. Just for my understanding (maybe I can run a debug session on the weekend): the function ltdb_handle_request checks for controls with the "critical" bit set and returns LDB_ERR_UNSUPORTED_CRITICAL_EXTENSION if there is one. But who shall remove the control and / or resetting the critical bit? To me the patch of util.c looks like it's adding the control again (which should fail).

Maybe I'm just missing a patch file that was not mentioned here.

Comment 3 Andrew Bartlett 2010-02-22 04:47:06 UTC
Can you determine which critical control causes it to fail?  it should be in the error string returned over LDAP.  Or just attach to the server with gdb and break in ltdb_handle_request.

Comment 4 Simo Sorce 2010-02-22 06:44:06 UTC
I added the permissive modify control only on Jan 30 with commit df7be036d7b4e08b18bd03399847dad41b78be50

It wasn't available in alpha11. It's fixed in master.
Comment 5 Christoph Theis 2010-02-22 12:53:38 UTC
(In reply to comment #3)
> Can you determine which critical control causes it to fail?  it should be in
> the error string returned over LDAP.  Or just attach to the server with gdb and
> break in ltdb_handle_request.

It was the permissive modify control. But I installed just the 3 patches you mentioned above and so I missed the patch Simo mentions below. I will apply this patch, too, as it looks like it skips the permissive modify control when checking for critical extensions, and will report if it still fails.

Thanks a lot for your help.
Comment 6 Andrew Bartlett 2010-02-22 16:04:43 UTC
Ahh, I was under the impression you had simply updated to current master.  Generally we need those reporting bugs to re-test against master, or at least after the revisions we indicate, as very few of our patches are designed to be run in isolation against previous versions.