[Samba] [SOLVED] roaming profile does ­­not ­work for "Domain Ad­m­ins"

[Davor Vusir]

2014-10-31 0:19 GMT+01:00 ?icro MEGAS <micromegas at mail333.com>:
>> HI Mirco, Isn't samba4 AD wonderful, the way it works just like a
>> windows AD DC :-)
>>
>> Yes, the problem you having isn't a problem, it is the way that
>> microsoft designed it, see here:
>>
>> https://social.technet.microsoft.com/Forums/windowsserver/en-US/7f03c07e-5a71-4ff3-abc1-50d3c14bf982/why-do-roaming-profiles-exclude-domain-admin-access?forum=winserverGP
>> Rowland
>
> Dear Rowland,
>
> I do not agree because
>
> a.) at last I did find the culprit which was causing that problem. I am glad that I *SOLVED IT* but on the other side I'm kinda disappointed because the root of that evil is your so highly-praised "smbmap" feauture which already caused a lot of discussion here on the list. I will get in detail and explain on the bottom of this message
>
> b.) the link you posted is a completely different issue. The issue reported there is that roaming profiles created by Windows by default allow only the creator/owner and SYSTEM to access it and noone else. For example: when user "johndoe" logs in for the first time and his roaming profile is created, the directory \\server\sharename\johndoe has only two objects in the Windows Security Settings. They are "johndoe" itself and "SYSTEM". Noone else has access to it. Many administrators hate this default behaviour because they cannot browse the files in these directories although they are domain admins. I told you the reason why they cannot. This issue is explained and discussed on many other sites around the net. Just google for "roaming profile domain admins" and you will find a lot of hits, as well some tech sheets and explanations from Microsoft or even some workaround with neat scripts.
>
> Well, now back to point a.) the explanation why I ran into that issue. As I stated before, the root of the evil was the "smbmap" feauture. How I found out? On the fresh-new Win7 machine I installed for my tests, I got some more detailled information on the event viewer and I saw a message in there for the failing "roaming profile". It explained in detail, that the user *must be owner of the roaming profile directory*. The solution is to make the user the owner of their profile folder. And now guess why the directories of these three administrators had following owner/group assigned:
>
> root:root  johndoe.v2
> root:root  foobar
> root:root  admin3
>
> I tell you, because when you use the smbmap feauture as suggested many times by you, the user itself becomes "root" to the machine and windows only see "root" but expects "foobar" and *THAT'S THE CULPRIT*. As you realized in the past days, I reported some issues to the samba lists where the "smbmap" feauture again was causing headache. Now after that horrible scenario I had to face, and moreover so many hours I had to spent, I certainly am sure *NOT TO USE* the *username map* directive in future and now I understand why a few days ago a samba developer suggested me NOT TO USE it. I should have listened to him.
>
When I look at Samba I see a pretty much selfcontained system,
somewhat separated from Linux that uses the Linux OS as a vessel for
its purposes. Samba is also designed to be administrated from various
MMCs "the Windows way".

When the Linux/samba-server is configured and up and running, you need
only do three things with root:
1) Fix things if something goes south.
2) Create a new share definition in smb.conf.
3) See to that appropriate domain user account and group is set as
owner and group on the directory to be shared.

The rest is handled from Windows.

If you configure the sudo facility (Microsoft has got UAC), you can do
2) and 3) with a domain account and truly can consider the root
account as equivalence to the local administrator account on a Windows
(member) server.

Mirco, your explanation above is accurate. Well put! Using 'smbmap'
is, at its best, obsolete and should not be used. The right way to go
is to assign uidNumber and gidNumber to all domain accounts and
groups, built-in or man-made which an interpretator like winbind uses.

In a larger IT environment/ecosystem you would delegate all file
server administration to a storage-/fileservergroup. To examplify:
1. Create a domain group with gidNumber assigned: DOMAIN\FileServerAdmins.
2. Create a domain account with uid- and gidNumber assigned:
DOMAIN\FileSystemOwner.
3. Create a domain accounts with uid- and gidNumber assigned for each
fileserveradmin: DOMAIN\FSAdmin1, DOMAIN\FSAdmin2, DOMAIN\FSAdminN.
4. Add the accounts FileSystemOwner and fileserveradmins to the group
DOMAIN\FileServerAdmins.
5. Add DOMAIN\FileServerAdmins to the local administrator group on the
Sambaserver using Computer Management MMC.
6. Run the command "chown -R
'DOMAIN\FileSystemOwner':'DOMAIN\FileServerAdmins' /path/to/share".
7. Connect to the file server with Computer Management and change both
Share ACL and Security ACLs to reflect the need.

Other bonus that comes with this approach, considering that, as soon
as you add NTFS ACLs, POSIX ACLs changes from 755 to the somewhat too
generous 770, is that you are able to secure the file system in a
better manner.

Regards
Davor

> You can read the technical details and see also the event viewer message that was logged on my Win7 workstation which helped me to find out the culprit. Although they are related to other Windows versions, the event viewer message is exactly the same, as I did receive it on my Win7 machine. The content is self-explanatory, read here:
>
> http://support.microsoft.com/kb/327259
> http://support.microsoft.com/kb/327462
>
> Cheers,
> Mirco.
> --
> To unsubscribe from this list go to the following URL and read the
> instructions:  https://lists.samba.org/mailman/options/samba