I suggest to the op check my settings and try it. Should work. Not showing the security tab is often an wrong right in the underlaying folder. So in case of this one, i would check this first. ls -al /data/ ls -al /data/samba ls -al /data/samba/profiles chmod 775 /data/ ! In case of a chmod 770 or 750 make sure you have a group set that is known in windows. Same for /data/samba chmod 1777 for /data/samba/profiles Then when createing/settings the profiles in windows tools, first set the UNIX UID, klik apply. Now set the profiles path, it should result in # file: home/samba/profiles/username.V6 # owner: username # group: domain\040users user::rwx user:username:rwx group::--- group:2005:rwx group:domain\040users:--- mask::rwx other::--- default:user::rwx default:user:obell:rwx default:group::--- default:group:2005:rwx default:group:domain\040users:--- default:mask::rwx default:other::--- Do note the UID 2005, that is the one that created the folder. ( user : SYSTEM ) Greetz, Louis> > > The problem isn't whether 'Domain Admins' has a gid or not, the OP > cannot open the security tab on windows as Administrator. > > This is something I can only reproduce by not having a user.map in > smb.conf > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba > >
Hi Louis, I will give it a try when I'm back home in the evening. Thanks! Peter On 10/10/18 11:18 AM, L.P.H. van Belle via samba wrote:> I suggest to the op check my settings and try it. > Should work. > Not showing the security tab is often an wrong right in the underlaying folder. > > So in case of this one, i would check this first. > ls -al /data/ > ls -al /data/samba > ls -al /data/samba/profiles > > chmod 775 /data/ ! In case of a chmod 770 or 750 make sure you have a group set that is known in windows. > Same for /data/samba > > chmod 1777 for /data/samba/profiles > Then when createing/settings the profiles in windows tools, first set the UNIX UID, klik apply. > Now set the profiles path, it should result in > > # file: home/samba/profiles/username.V6 > # owner: username > # group: domain\040users > user::rwx > user:username:rwx > group::--- > group:2005:rwx > group:domain\040users:--- > mask::rwx > other::--- > default:user::rwx > default:user:obell:rwx > default:group::--- > default:group:2005:rwx > default:group:domain\040users:--- > default:mask::rwx > default:other::--- > > Do note the UID 2005, that is the one that created the folder. ( user : SYSTEM ) > > Greetz, > > Louis > > >> >> The problem isn't whether 'Domain Admins' has a gid or not, the OP >> cannot open the security tab on windows as Administrator. >> >> This is something I can only reproduce by not having a user.map in >> smb.conf >> >> Rowland >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba >> >> >
On 10.10.2018 11:18, L.P.H. van Belle via samba wrote:> I suggest to the op check my settings and try it. > Should work. > Not showing the security tab is often an wrong right in the underlaying folder. > > So in case of this one, i would check this first. > ls -al /data/ > ls -al /data/samba > ls -al /data/samba/profiles > > chmod 775 /data/ ! In case of a chmod 770 or 750 make sure you have a group set that is known in windows. > Same for /data/samba > > chmod 1777 for /data/samba/profiles > Then when createing/settings the profiles in windows tools, first set the UNIX UID, klik apply. > Now set the profiles path, it should result in > > # file: home/samba/profiles/username.V6 > # owner: username > # group: domain\040users > user::rwx > user:username:rwx > group::--- > group:2005:rwx > group:domain\040users:--- > mask::rwx > other::--- > default:user::rwx > default:user:obell:rwx > default:group::--- > default:group:2005:rwx > default:group:domain\040users:--- > default:mask::rwx > default:other::--- > > Do note the UID 2005, that is the one that created the folder. ( user : SYSTEM ) > > Greetz, > > Louis >Hi Louis and Rowland, A big thank you for pushing me to continue this. Thanks to your help, things are working as they should, and that one would expect. For the curious, the final smb.conf for the Samba member server is below this message. What I did, was to implement the smb.conf I got from Rowland. As I do not want *any* Samba users logging on with ssh, the template homedir = /dev/null, and template shell = /bin/nologin. After that, I created the /data/samba/profiles directory, set the ownership, and permissions according to Louis' instructions above. I also checked up and made sure that only BUILTIN\Administrators SeDiskOperatorPrivilege, SeSecurityPrivilege, and SeTakeOwnershipPrivilege had got those privileges set. Domain Admins inherit this from BUILTIN\Administrators, so there is no point in setting this for Domain Admins. The rest was made through Windows Computer Management. What is different from the Samba Wiki, is the default share permission. It's set to Everyone with full privileges. It definitely has got implications, if something else is set (probably for the worse). Further on, in the security tab, everything was setup according to the Wiki. Testing the share, it behaves exactly as expected. After that, I assigned roaming profiles to a couple of users through the Profile tab in the ADUC tool (\\smbtest\Profiles$\<username>). Worked according to the book. The profile folder is not displayed when browsing the server (the $ sign), and if it's an advanced user who knows the trick with the $-sign, no other folder than the user's own profile folder is displayed. Profiles are correctly created, retrieved and stored at logon and logoff. When checking the folders, all ownerships are set correctly. There is just one crucial point, however. Always keep the default share owner (unix root). Never mix in the Administrator account in the shares. At least in my setup, it seems Samba sometimes uses Administrator, and sometimes root when setting ownership, and permissions. Stick to root keeping ownership of the share. Thanks a lot to those who have contributed to the success! Great work! Best regards, Peter smb.conf ======= [global] workgroup = PRIVATE realm = PRIVATE.LOCAL security = ADS server string = Private server %h username map = /etc/samba/user.map winbind use default domain = true winbind expand groups = 2 winbind refresh tickets = Yes winbind offline logon = true idmap config * : backend = tdb idmap config * : range = 3000-7999 idmap config PRIVATE:backend = rid idmap config PRIVATE:range = 10000-99999 # template homedir = /home/%U template homedir = /dev/null # template shell = /bin/bash template shell = /bin/nologin local master = no domain master = no preferred master = no os level = 20 map to guest = bad user host msdfs = no # winbind enum users = yes # winbind enum groups = yes printing = bsd printcap name = /dev/null load printers = no disable spoolss = yes vfs objects = acl_xattr map acl inherit = yes store dos attributes = yes acl_xattr:ignore system acl = yes hide unreadable = yes veto files = /.bash_logout/.bash_profile/.bash_history/.bashrc/ unix extensions = no reset on zero vc = yes [Profiles$] readonly = no path = /data/samba/profiles acl_xattr:ignore system acl = yes [Users$] readonly = no path = /home/%U [Wanda] readonly = no path = /data/samba/wandafish
Hai Peter, Good to hear its fixed.> Hi Louis and Rowland, > > A big thank you for pushing me to continue this. Thanks to your help, > things are working as they should, and that one would expect. For the > curious, the final smb.conf for the Samba member server is below this > message. > > What I did, was to implement the smb.conf I got from Rowland. As I do > not want *any* Samba users logging on with ssh, the template > homedir = > /dev/null, and template shell = /bin/nologin.The other option is, setup a group in windows give it a GID and put the group in ssh. For example i use it 3 ways, like this: AllowGroups sftp-customer servers-ssh sshgroup I use MySecureShell for my SFTP users, and these must exist in the sftp-customers group. ( a windows group with GID ) The servers-ssh is use to allow logins. The sshgroup is the backup group with only linux members in them, admins only. Working like that you can control everything from within the AD. Your option also works, in case you want to enable it, you need to adjust the smb.conf. I only add a user to a group. Think whats best for you, you deside.> > After that, I created the /data/samba/profiles directory, set the > ownership, and permissions according to Louis' instructions above. I > also checked up and made sure that only BUILTIN\Administrators > SeDiskOperatorPrivilege, SeSecurityPrivilege, and > SeTakeOwnershipPrivilege had got those privileges set. Domain Admins > inherit this from BUILTIN\Administrators, so there is no point in > setting this for Domain Admins. > > The rest was made through Windows Computer Management. > > What is different from the Samba Wiki, is the default share > permission. > It's set to Everyone with full privileges. It definitely has got > implications, if something else is set (probably for the worse).You have 2-3 options here to setup. - Use everyone. Restricting the folder rights is key here to protect you network. - Setup with "authenticated users" , you need more groups and you might to change (default) GPO settings. - Only custom groups, same as authenticated users but more todo. Best tip here is, just setup as windows does, then it just works. ( keep everyone )> > Further on, in the security tab, everything was setup > according to the > Wiki. Testing the share, it behaves exactly as expected. > After that, I > assigned roaming profiles to a couple of users through the > Profile tab > in the ADUC tool (\\smbtest\Profiles$\<username>). Worked > according to > the book. The profile folder is not displayed when browsing > the server > (the $ sign), and if it's an advanced user who knows the > trick with the > $-sign, no other folder than the user's own profile folder is > displayed.You can use: browseable = no also. That hides the share and no need for the $. This might help if you have cifs connections and scripting things.> Profiles are correctly created, retrieved and stored at logon > and logoff. > > When checking the folders, all ownerships are set correctly. There is > just one crucial point, however. Always keep the default share owner > (unix root). Never mix in the Administrator account in the shares. At > least in my setup, it seems Samba sometimes uses Administrator, and > sometimes root when setting ownership, and permissions. Stick to root > keeping ownership of the share.I can suggest even a few extra tips. Create a new user : Admin, add him on to the domain admins, and give him a UID Set as the normal Administrator and now use only Admin. Done and now you never encounter the root/Administrator problems. I follow these few rules. I use Administrator for my windows management things on only one pc. DNS RSAT GPOS etc. Why, because of username map = /etc/samba/user.map. More explained, Administrator is mapped to root (vicaversa) and on linux you need root not admin. I use Admin for regular thing to manage pc's printers etc. do note, due to above this account cannot mananage linux, or you need to add the mapping. I have separated that. If you add the mapping, dont forget the SePrivileges and the assigned users/groups with that. I never use root, and it has login disable.> > Thanks a lot to those who have contributed to the success! Great work! > > Best regards, > > Peter > > >Your welkom, Greetz,,, Louis
Mandi! L.P.H. van Belle via samba In chel di` si favelave...> > What I did, was to implement the smb.conf I got from Rowland. As I do > > not want *any* Samba users logging on with ssh, the template > > homedir = /dev/null, and template shell = /bin/nologin. > The other option is, setup a group in windows give it a GID and put the group in ssh.I suggest this option, because setting an invalid shell to users have some little collacteral effects, as the neet to explicit the shell when you have to run script in behalf of that users (eg, su -s /bin/sh ...). -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia'' http://www.lanostrafamiglia.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)lanostrafamiglia.it t +39-0434-842711 f +39-0434-842797 Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA! http://www.lanostrafamiglia.it/index.php/it/sostienici/5x1000 (cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA)
On 11.10.2018 10:55, L.P.H. van Belle via samba wrote:> Hai Peter, > > Good to hear its fixed. > >> Hi Louis and Rowland, >> >> A big thank you for pushing me to continue this. Thanks to your help, >> things are working as they should, and that one would expect. For the >> curious, the final smb.conf for the Samba member server is below this >> message. >> >> What I did, was to implement the smb.conf I got from Rowland. As I do >> not want *any* Samba users logging on with ssh, the template >> homedir >> /dev/null, and template shell = /bin/nologin. > The other option is, setup a group in windows give it a GID and put the group in ssh. > For example i use it 3 ways, like this: > AllowGroups sftp-customer servers-ssh sshgroup > I use MySecureShell for my SFTP users, and these must exist in the sftp-customers group. ( a windows group with GID ) > The servers-ssh is use to allow logins. > The sshgroup is the backup group with only linux members in them, admins only. > Working like that you can control everything from within the AD. > > Your option also works, in case you want to enable it, you need to adjust the smb.conf. > I only add a user to a group. > > Think whats best for you, you deside. > >> After that, I created the /data/samba/profiles directory, set the >> ownership, and permissions according to Louis' instructions above. I >> also checked up and made sure that only BUILTIN\Administrators >> SeDiskOperatorPrivilege, SeSecurityPrivilege, and >> SeTakeOwnershipPrivilege had got those privileges set. Domain Admins >> inherit this from BUILTIN\Administrators, so there is no point in >> setting this for Domain Admins. >> >> The rest was made through Windows Computer Management. >> >> What is different from the Samba Wiki, is the default share >> permission. >> It's set to Everyone with full privileges. It definitely has got >> implications, if something else is set (probably for the worse). > You have 2-3 options here to setup. > - Use everyone. Restricting the folder rights is key here to protect you network. > - Setup with "authenticated users" , you need more groups and you might to change (default) GPO settings. > - Only custom groups, same as authenticated users but more todo. > > Best tip here is, just setup as windows does, then it just works. ( keep everyone ) > >> Further on, in the security tab, everything was setup >> according to the >> Wiki. Testing the share, it behaves exactly as expected. >> After that, I >> assigned roaming profiles to a couple of users through the >> Profile tab >> in the ADUC tool (\\smbtest\Profiles$\<username>). Worked >> according to >> the book. The profile folder is not displayed when browsing >> the server >> (the $ sign), and if it's an advanced user who knows the >> trick with the >> $-sign, no other folder than the user's own profile folder is >> displayed. > You can use: browseable = no also. > That hides the share and no need for the $. > This might help if you have cifs connections and scripting things. > >> Profiles are correctly created, retrieved and stored at logon >> and logoff. >> >> When checking the folders, all ownerships are set correctly. There is >> just one crucial point, however. Always keep the default share owner >> (unix root). Never mix in the Administrator account in the shares. At >> least in my setup, it seems Samba sometimes uses Administrator, and >> sometimes root when setting ownership, and permissions. Stick to root >> keeping ownership of the share. > I can suggest even a few extra tips. > > Create a new user : Admin, add him on to the domain admins, and give him a UID > Set as the normal Administrator and now use only Admin. > Done and now you never encounter the root/Administrator problems. > > I follow these few rules. > I use Administrator for my windows management things on only one pc. DNS RSAT GPOS etc. > Why, because of username map = /etc/samba/user.map. > More explained, Administrator is mapped to root (vicaversa) and on linux you need root not admin. > > I use Admin for regular thing to manage pc's printers etc. > do note, due to above this account cannot mananage linux, or you need to add the mapping. I have separated that. > If you add the mapping, dont forget the SePrivileges and the assigned users/groups with that. > > I never use root, and it has login disable. > > >> Thanks a lot to those who have contributed to the success! Great work! >> >> Best regards, >> >> Peter >> >> >> > > > Your welkom, > > Greetz,,, > > Louis > >Hi Louis, Thanks for the extra tricks and tips here. They may come in handy some time else. The current installation is a very restricted setup. Windows only access for ordinary users, and strictly compartmentalized, depending on each users function. Previously, I had problems when using the documented user groups (Domain Admins, and Domain Users) on the share. Then I got a blank security tab. I'm perfectly happy to keep Everyone. An arbitrary user without additional privileges, isn't getting anywhere here. I prefer to keep the $-sign in the share name. It's the M$ way. So I'll stick to that. Scripting works anyway under Linux, $-sign or not. If the current user base wants to play with Linux, they are free to do so. At home, and in their spare time. While working, no way... Setting up the Admin user is interesting. I will try that. But I could as well add myself to the domain admins group. The name is arbitrary. I already apply split accounts under Windows and Linux. Logging in to Linux hosts I use local accounts, with names that are distinct from those used under Windows. Thanks for your input, and I wish you a nice day! Peter
Hai, small note here..> > Setting up the Admin user is interesting. I will try that. > But I could as well add myself to the domain admins group. > The name is arbitrary.Yes the name is but now you are working with Admin rights. Never ever do that. Please dont, use the UAC. It's so easy to get infected if you work as admin so dont.. Personaly here, at the office, i have the same restrictions as every other user. Except i can overrule it with UAC, but i never work with admin rights ever, not even at home. Greetz, Louis