Bug 11881 - samba-tool dbcheck --fix breaks Terminal Services Environment on user
Summary: samba-tool dbcheck --fix breaks Terminal Services Environment on user
Status: NEW
Alias: None
Product: Samba 4.1 and newer
Classification: Unclassified
Component: AD: LDB/DSDB/SAMDB (show other bugs)
Version: 4.4.2
Hardware: All All
: P5 normal (vote)
Target Milestone: ---
Assignee: Andrew Bartlett
QA Contact: Samba QA Contact
Depends on: 8077
  Show dependency treegraph
Reported: 2016-04-29 19:55 UTC by Saso Slavicic
Modified: 2016-07-28 23:56 UTC (History)
3 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Saso Slavicic 2016-04-29 19:55:16 UTC
After upgrading from samba4-4.1.18 to samba4-4.4.2 I ran 'samba-tool dbcheck'. It reported some errors with userParameters:

ERROR: wrongly formatted userParameters on
CN=,OU=Users,OU=MyBusiness,DC=,DC=local, should not be psudo-UTF8 encoded.

This domain was originally created on SBS 2003, which was later demoted and it's now exclusivly handled by samba4. Some users in this domain have Terminal Services Environment set to run some program on login.

After running samba-tool dbcheck --fix, all the Terminal Services fields are empty in Windows AD Users & Computers console. Trying to change this field to previous values:

 - closes the AD U&C console on Windows XP without any error
 - outputs "The parameter is incorrect" on Windows 7

The field remains empty in all cases, can't be changed and it isn't working.

Reverting domain data (samba4 private subdirectory) from before running samba-tool dbcheck --fix appears to restore the functionality. Even with version 4.4.2, this fields can be modified and appears to be working fine.

I can provide LDAP value of userParameters field before and after running --fix if it helps.
Comment 1 Saso Slavicic 2016-04-29 20:01:23 UTC
Just an additional note, I do believe the Terminal Services Environment was set by samba4, after SBS 2003 migration, not before. Samba version at the time of creating TS Environment was probably 4.1.5.
Comment 2 Andrew Bartlett 2016-04-29 21:40:06 UTC
Yes, before and after values will be critical.
Comment 4 Andrew Bartlett 2016-04-29 22:17:01 UTC
Thanks.  I've marked the comment private to team members in case it contains private paths.
Comment 5 trenta 2016-07-16 08:43:39 UTC
any news about this issue, same problem.
with samba 3 domain was working?
Comment 6 Andrew Bartlett 2016-07-19 22:17:24 UTC

I realise this is a big issue for you, and that Samba is not behaving well in your situation.

What we need written is an end-to-end test, comfirming inputs and outputs via:

 - s3/passdb (as used by classicupgrade)
 - s4/samr
 - s4/ldap
 - s4/netlogon (the info3 reply)
 - the PAC in the krb5 reply (but this will be mostly covered by getting the s4/netlogon server right, as much of that code is in common).

Then we need to confirm that a dbcheck passes against the correctly specified inputs, and doesn't 'fix' them to be broken.

That much is the time consuming part.  I would suggest writing this in python, using the python bindings for ldb, passdb and samr in particular.

The fix is probably something pretty simple, once we have a test to prove it.