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.
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.
Yes, before and after values will be critical.
Thanks. I've marked the comment private to team members in case it contains private paths.
any news about this issue, same problem. with samba 3 domain was working?
Thanks. 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.