samba - Apr 2016 - Samba 4.4 userParameters problems

Hi,

I recently upgraded 4.1.8 installation to 4.4.2. As per documentation I ran
samba-tool dbcheck. It reported some problems with userParameters:

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

I ran --fix as I read in some discussion that this was actually tested.

The problem after upgrade is, that it is no longer possible to set Terminal
Services Environment on the user via Windows RSAT. All the fields are empty,
if anything is set (Start the following program at logon: "Program file
name" or "Start in"), an error is returned after applying:
"The parameter is
incorrect" and the field is emptied again. These fields are stored in
userParameters AD attribute.
I have restored samba4 private subdir from before the upgrade and the fields
are correctly set and can be changed normally.

I've tried downgrading to 4.4.0 to see if it's caused by badlock fixes,
but
I experienced the same problem.
Can I do anything to help diagnosing the problem?

Regards, Saso

On Thu, 2016-04-28 at 21:47 +0200, Saso Slavicic wrote:
> Hi,
> 
> I recently upgraded 4.1.8 installation to 4.4.2. As per documentation
> I ran
> samba-tool dbcheck. It reported some problems with userParameters:
> 
> ERROR: wrongly formatted userParameters on
> CN=,OU=Users,OU=MyBusiness,DC=,DC=local, should not be psudo-UTF8
> encoded.
> 
> I ran --fix as I read in some discussion that this was actually
> tested.
Yes, we have some tests to try and ensure the dbcheck does something
reasonable.
> The problem after upgrade is, that it is no longer possible to set
> Terminal
> Services Environment on the user via Windows RSAT. All the fields are
> empty,
> if anything is set (Start the following program at logon: "Program
> file
> name" or "Start in"), an error is returned after applying:
"The
> parameter is
> incorrect" and the field is emptied again. These fields are stored in
> userParameters AD attribute.
> I have restored samba4 private subdir from before the upgrade and the
> fields
> are correctly set and can be changed normally.
> 
> I've tried downgrading to 4.4.0 to see if it's caused by badlock
> fixes, but
> I experienced the same problem.
> Can I do anything to help diagnosing the problem?
Any upgrade past 4.2.0 will hit this, as I recall.

Fixing this all up properly isn't going to be trivial:  We need to
write full round-trip tests that set proper terminal services values
into this attribute, replicate it, and confirm everything is OK on the
replica and in the DB.  Ideally we even find a way to match the MS
behaviour when this is returned over LDAP.

I know it really sucks, but I've looked into this quagmire before, and
it is non-trivial to untangle.  I'm sad to hear our current state is so
broken, I had hoped this much at least was working.

You are welcome to file a bug, however you would also be well advised
to contact a commercial support provider if you need this fixed
urgently.

https://www.samba.org/samba/support/globalsupport.html

Thanks,

Andrew Bartlett

-- 
Andrew Bartlett                       http://samba.org/~abartlet/
Authentication Developer, Samba Team  http://samba.org
Samba Developer, Catalyst IT          http://catalyst.net.nz/services/samba