[Samba] ad dc roaming new user profile folders not being created on login

Fri Jan 24 16:53:08 UTC 2020

Hi Everyone,

I have a debian server(1) running samba as ad dc with roaming profiles. It's been working just about flawlessly for many years now. Last night I went to add a user- did the same I normally do and ran my little script(2) and proceeded to login as the user and get the account configured. Unfortunately, everything came to a screeching halt when I was presented with a temp profile and the ungodly suggestion from MS to signout to fix the problem.

At this point I have no idea what the source of the issue is so I'll forgo the speculation and present to you what I feel are relevant facts and hopefully you can help me work this out.

a) The user is allowed to login on any domain computer and is getting a temp profile on every system I've tried to login to.
b) I have only 2 GPOs in place. The GPOs are being applied but the work can't be carried out because the profile cannot be created. The GPOs have been working for several years.
 b1) redirected folders which is working
 b2) a few mapped drives
c) The account in question can successfully navigate to the profiles/netlogon/sysvol shares located on the samba dc
d) The account can also successfully navigate to the redirected folders share which is on a domain member and open each folder (Documents, Favorites, Downloads, Cookies). The profiles are not stored on this server. They're stored on the dc.
e) all existing users continue to use their roaming profiles without issue; it is only new accounts that cannot create the profile
f) I've created several new test accounts and logged into different domain members in the network and get the same issue.
g) I've rebooted both servers and the computers just to clear any anomaly to no avail
h) I can ping the server and browse to all the required shares using FQDN
i) all acl permissions were implemented using FQDN from a windows 7 domain member
j) samba logs show no errors at all (rather surprising imo)

So here's one thing which is the most recent change I made(4) however, this could easily be a coincidence imo. For the life of me I have never managed to get domain accounts to be recognized on the local DC or the other linux server domain member (aka my file server). So I've been forced to apply very loose filesystem permissions and restrict access via ACLs from Windows- which has worked fairly well. About a week and a half ago finally realized I was failing to install a package related to winbind which finally resolved that specific issue. Great! Now domain accounts are successfully recognized on the local dc and linux domain members. That said, I ***did not change any filesystem permissions at that time***. Maybe that is my mistake but in my mind, I was happy having resolved it after all these years and was planning on testing and implementing more restrictive fs permissions at a later date. But again, I don't see this being relevant in the creation of the profiles folders since c) works perfectly and the permissions on the share are set as per the samba4 ad dc wiki(3).

Based on what I've already tried I have no idea what the issue could be. I'm hoping to keep it simple here but I think with the novel I jsut wrote I'm already passed that smh...

references
(1)

1.1) ad dc server details
samba 4.2.14+dfsg-0+deb8u13  amd64
3.16.0-10-amd64 #1 SMP Debian 3.16.76-1 (2019-11-12) x86_64

1.2)smb.conf
# Global parameters
[global]
workgroup = INTRANET
realm = INTRANET.BLANKED.CA
netbios name = SVR11
server role = active directory domain controller
dns forwarder = 8.8.8.8
idmap_ldb:use rfc2307 = yes
map acl inherit = yes
client ldap sasl wrapping = sign

# Default idmap config for local BUILTIN accounts and groups
idmap config * : backend = tdb
idmap config * : range = 3000-7999

# idmap config for the INTRANET domain
idmap config INTRANET:backend = ad
idmap config INTRANET:schema_mode = rfc2307
idmap config INTRANET:range = 10000-999999

# Template settings for login shell and home directory
winbind nss info = template
template shell = /bin/bash

[netlogon]
path = /var/lib/samba/sysvol/intranet.blanked.ca/scripts
read only = No

[sysvol]
path = /var/lib/samba/sysvol
read only = No

[profiles]
path = /data/profiles
read only = no

***on a side note, all the id mapp stuff and some other settings were implemented years ago in a desperate attempt to fix another issue. I've implemented several samba dc's since then and not needed any of that but felt that since everything was working well there was no sense removing any of it. Keep in mind we're talking years here but if the consensus is to remove those entries I'm onboard with that.

2) user create script
#/bin/bash
echo Surname?
read surname
echo Given Name?
read givenname
echo username?
read username
samba-tool user create $username --surname=$surname --given-name=$givenname --profile-path=\\\\SVR.intranet.BLANKED.ca\\profiles\\$username
samba-tool user setexpiry $username --noexpiry

***on a side note to this one, I also tested creating test accounts using AD user and computers on a windows 7 domain member with RSAT (which is what I used to do before that script) and saw no difference

Here is the only error I've managed to find. The problem I have with diving into that one is that in the 15+ years since I've implemented roaming profile sin samba I've never had to open the "Component Services" tool. So I have a lot of reservations about doing so. Here's the error I get on any computer I log into using a newly created account since this issue has come up. I do not get this on user account for which profiles are successfully working.

The machine-default permission settings do not grant Local Activation permission for the COM Server application with CLSID
{C2F03A33-21F5-47FA-B4BB-156362A2F239}
 and APPID
{316CDED5-E4AE-4B15-9113-7055D84DCC97}
 to the user INTRANET\klund SID (S-1-5-21-2383363326-2467922837-4208427301-1227) from address LocalHost (Using LRPC) running in the application container Microsoft.Windows.ShellExperienceHost_10.0.18362.449_neutral_neutral_cw5n1h2txyewy SID (S-1-15-2-155514346-2573954481-755741238-1654018636-1233331829-3075935687-2861478708). This security permission can be modified using the Component Services administrative tool.

3) FS permissions on the profiles share are set as per: https://wiki.samba.org/index.php/Roaming_Windows_User_Profiles#Using_Windows_ACLs

4) Turns out I was missing libnss-winbind and libpam-winbind all this time. After installing those, getent and all winbind type queries are working successfully. Hopefully my issue isn't related to having fixed that issue!

https://lists.samba.org/archive/samba/2016-July/201400.html

Thank you in advance for taking the time to read this novel and any attempt you make in helping me resolve this. If I make any further changes or achieve any progress I'll be certain to update this thread.

Cheers, Phil