Univention Bugzilla – Bug 50442
Use FQDN in sambaHomePath
Last modified: 2023-06-08 13:42:59 CEST
Starting with Windows 10 1809, the windows client complains if the sambaHomePath attribute contains only a hostname but no FQDN.
FYI: 1. They introduced UNC path hardening for GPOs in 2015: https://msrc-blog.microsoft.com/2015/02/10/ms15-011-ms15-014-hardening-group-policy/ 2. For automatic printer distribution (pushedPrinterConnection GPO) of non-package-aware printer drivers Microsoft published a workaround that explicitly requires the use of FQDN server names (MS16-087, see Bug 43252 Comment 5). So, while I could not find a quote about a change in Windows 10 1809, this is not without precedent.
I could not reproduce the originally reported problem (error message regarding profile) with a Windows 10 Pro Version 1809 Build 17763.805. The Windows is freshly installed and equipped with all available updates that Microsoft offers online. In the UCS@school environment, Windows was only joined to the UCS@school domain. No further adjustments were made to the Windows client or the AD (e.g. GPOs). I.e. Out-Of-The-Box the profile worked for the first time. For my tests I created several users with different LDAP settings (see below), but no combination showed (the) problems reliably. uid: anton1 sambaHomePath: \\slave213\anton1 sambaProfilePath: %LOGONSERVER%\%USERNAME%\windows-profiles\default uid: anton2 sambaHomePath: \\slave213.nstx212.ucs\anton2 sambaProfilePath: %LOGONSERVER%\%USERNAME%\windows-profiles\default uid: anton3 sambaHomePath: \\schulserver\anton3 sambaProfilePath: %LOGONSERVER%\%USERNAME%\windows-profiles\default uid: anton4 sambaHomePath: \\schulserver.nstx212.ucs\anton4 sambaProfilePath: %LOGONSERVER%\%USERNAME%\windows-profiles\default uid: anton5 sambaHomePath: \\slave213\anton5 sambaProfilePath: %LOGONSERVER%\%USERNAME%\windows-profiles\default uid: anton6 sambaHomePath: \\slave213\anton6 sambaProfilePath: \\slave213\%USERNAME%\windows-profiles\default uid: anton7 sambaHomePath: \\slave213\anton7 sambaProfilePath: \\slave213.nstx212.ucs\%USERNAME%\windows-profiles\default The first login (profile creation) and a new login was successful for all users. No error message due to profile problems or so was displayed. The icons are all present on the desktop. If you now delete the link to the UCS portal from the desktop, open the Explorer and change to \\slave213\netlogon and execute the Netlogonscript "ucs-school-logon.vbs" there, the link will be restored for all users. However, with anton1 and anton3 the UCS icon on the shortcut is not set (only the default icon). This is also reproducible for these users. However, anton5 has the same settings as anton1 and there the problem *does not* occur. If someone has useful hints for me on how to reproduce this, please add it to this bug.
Short version of the analysis I did for the UCS@school team (Email 7.11.): I guess there were (at least) two parallel stories going on at that ticket: 1) The error popup "user\%USERNAME%.vbs failed with error code: 1" on the Windows client. In this case we would have needed to retrieve the log file %TEMP%\%USERNAME%-ucs-school-netlogon.log from the Windows client of the customer to see what went wrong. I guess the error popup message should be improved as a first step to catch this next time. 2) The customer then did experiments accessing //<server IP>/netlogon and that failed. To fix that "Hardened UNC Paths" / RequireMutualAuthentication has been disabled via GPO. That allows the share access via IP. It's not clear from the ticket that both issues are related.
This issue has been filed against UCS 4.4. UCS 4.4 is out of maintenance and UCS components may have vastly changed in later releases. Thus, this issue is now being closed. If this issue still occurs in newer UCS versions, please use "Clone this bug" or reopen this issue. In this case please provide detailed information on how this issue is affecting you.