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
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.
This should be fixed by tridge with http://gitweb.samba.org/samba.git/?p=samba.git;a=commitdiff;h=4694b4677ac58cd99d005d33aaf8c1b154e63b29, http://gitweb.samba.org/samba.git/?p=samba.git;a=commitdiff;h=2908f21c65ad8385f645cd841a25fe0f8f45feb0 and http://gitweb.samba.org/samba.git/?p=samba.git;a=commitdiff;h=05425fcf14f0695e5e230a698885203cc7c7ab2b.
Thanks for reporting this. If the problem still persists, please reopen!
(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.
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.
I added the permissive modify control only on Jan 30 with commit df7be036d7b4e08b18bd03399847dad41b78be50
It wasn't available in alpha11. It's fixed in master.
(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.
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.