[Samba] Samba4: "MYDOM\Administrator" quite useless on a member server?
Rowland Penny
rowlandpenny at googlemail.com
Mon Oct 27 14:44:33 MDT 2014
On 27/10/14 20:11, Davor Vusir wrote:
> Well, Mirco, sorry for hijacking your thread...
>
>
> 2014-10-27 15:41 GMT+01:00 L.P.H. van Belle <belle at bazuin.nl>:
>> I dont get this problem, so i did sum it up.
>>
>>
>>>>>>>>> Why does "getent group" *NOT* returning the AD domain groups.
>> answer, this is by design in samba. to save cpu load on the DC's as far as i know.
>> google for it. the devs already told this, its somewhere in the list also.
>>
>>>>>> isn't uid- and gidNumber to be considered the "bridge" to between the Windows-world and Linux-world?
>> answer, no it isnt, UID = UID , GID = GID, and has nothing to do with windows.
>> IMO. A windows user with a UID = just a linux user. ( depending where you login )
>>
> UID = UID, GID = GID. True. And SID = SID.
> In both MS ADS and Samba AD DC, rfc2307 is no-cost activation. And has
> got a low-cost maintenace. Why not use it? You have got more to gain
> than loose.
He wasn't saying don't use rfc2307, he was saying they are different and
mean different things to different OS's , you also got it wrong, an AD
user without a uidNumber is merely a windows user.
>
>>>>>>>>> I was told *NEVER* ever assign a UNIX attribute UID to the "MYDOM\Administrator"
>>>>>>>>> account on the [UNIX attribute] tab in ADUC tool.
>> Correct, you should NEVER assign any UID/GID to the Domain Administrator.
>> AND on a member server use the user mapping file/config.
>> AND you should not create a windows user account which exist already in linux!
>>
> Why not assign a uid- and gidNumber to Domain Administrator? It has no
> negative impact on neither MS ADS, Samba AD DC or the memberserver or
> -client.
Yes you are right about it having no impact on AD, but it will on Unix,
as I have pointed out to you, it will turn it into a normal user, who
will be able to do very little on a Unix machine.
> I don't agree with you on using a mapping file. Let me elaborate:
> When installing a Windows server or client, a (local) administrator
> account is configured. This account has got the well known SID
> 'S-1-5-21-domain-500'. In this case the "domain" is a number
> identifying this particular server. The installer also configures the
> (local) group Administrators with SID S-1-5-32-544.
You are using a samba machine as a member server in a windows domain, so
the 'Administrator' will need to be able to carry out various
administrative actions on the samba machine, to do this, 'Administrator'
needs to become 'root'. If this is done in a terminal, your
'Administrator' with a uidNumber would have to be able to run commands
with sudo, how do you add this user to sudo? and how does your
'Administrator' carry out these actions from a windows GUI (which knows
nothing about sudo) ?
We cannot stop you running your domain your way, we can only advise you
to run it the same way that the majority of people do.
I think that I have said all that I can say about this way of running
samba/windows, any further comment will be useless, you have made up
your mind and will not be talked out of it.
Rowland
>
> On my newly installed Windows server named TESTDC, it looks like this:
> C:\Users\Administrator>whoami /user
> USER INFORMATION
> ----------------
> User Name SID
> ==================== ============================================
> testdc\administrator S-1-5-21-241264005-3599872834-1040945704-500
>
> C:\Users\Administrator>psgetsid administrators
> PsGetSid v1.44 - Translates SIDs to names and vice versa
> Copyright (C) 1999-2008 Mark Russinovich
> Sysinternals - www.sysinternals.com
> SID for BUILTIN\administrators:
> S-1-5-32-544
> C:\Users\Administrator>
>
> On the future fileserver, TESTFS, it looks like this:
> C:\Users\Administrator>whoami /user
> USER INFORMATION
> ----------------
> User Name SID
> ==================== =============================================
> testfs\administrator S-1-5-21-2549290213-3252166228-4256938884-500
>
> C:\Users\Administrator>psgetsid administrators
> PsGetSid v1.44 - Translates SIDs to names and vice versa
> Copyright (C) 1999-2008 Mark Russinovich
> Sysinternals - www.sysinternals.com
> SID for BUILTIN\administrators:
> S-1-5-32-544
>
> C:\Users\Administrator>
>
> I promote the server TESTDC to Domain Controller and I get this info:
> C:\Users\Administrator>whoami /user
> USER INFORMATION
> ----------------
> User Name SID
> ======================== ============================================
> testdomain\administrator S-1-5-21-241264005-3599872834-1040945704-500
>
> C:\Users\Administrator>psgetsid administrators
> PsGetSid v1.44 - Translates SIDs to names and vice versa
> Copyright (C) 1999-2008 Mark Russinovich
> Sysinternals - www.sysinternals.com
> SID for BUILTIN\administrators:
> S-1-5-32-544
> C:\Users\Administrator>
>
> Please note similarities between SIDs of the server TESTDC and domain
> controller TESTDC. And note the differences in domain name.
>
> After joining TESTFS to Windows domain TESTDOMAIN, I run the same
> commands in different contexts:
> Efter domainjoin:
> logged on with the local administrator:
> C:\Users\Administrator>whoami /user
> USER INFORMATION
> ----------------
> User Name SID
> ==================== =============================================
> testfs\administrator S-1-5-21-2549290213-3252166228-4256938884-500
> C:\Users\Administrator>
>
> Logged on as Domain Administrator:
> C:\Users\administrator.TESTDOMAIN>whoami /user
> USER INFORMATION
> ----------------
> User Name SID
> ======================== ============================================
> testdomain\administrator S-1-5-21-241264005-3599872834-1040945704-500
> C:\Users\administrator.TESTDOMAIN>
>
> There are two different SIDs belonging to two different domains. One
> server domain and one Windows domain. I think, when you use user
> mapping in Samba, you're just overriding (overloading?) the local
> administrator account with the Domain Administrator account. This is
> of course not correct. Personally I think that the sudo facility
> Rowland mentions is a better alternative. One alternative is to create
> a usermap resembling to the group mapping (net groupmap list) that
> maps root to 'S-1-5-21-domain-500'. In this case the (local)
> administrator account. Quite tasty too.
>
> When using 'smbmap', the Share Permissions has to set to FULL in order
> to be able to set acceptable NTFS ACLs. Changing 'Everyone' for, say,
> Domain Admins removes the possibility to edit ACLs on the Security tab
> completely. But running the command 'chown -R
> 'EXAMPLE\administrator':root /path/to/Samba/share' removes this
> restriction.
>
>>>>>>>>> Wouldn't it be better to advice to assign both uid- and gidNumbers to user accounts
>>>>>>> and gidNumbers to groups? For compatability sake?
>> No, samba documentation says, that this isnt needed, this is done by samba.
>> go read : https://wiki.samba.org/index.php/Setup_a_Samba_AD_Member_Server again. the part after the smb.conf example.
>> and read: https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC after teh Advantages part.
>>
>> Im thinking your mixing 2 things.
>>
> No, I think you're mixing it up. To get a consistent user mapping
> through the member servers and clients, winbind has got to use
> information from a central source where uidNumber and gidNumber is the
> glue. Using the tdb or rid backend is perfectly fine if consistensy
> isn't of any concern or are running Windows clients only.
>
>>>>>>> I have stopped using usermapping because I get the following error in smbd.log: ....
>> and you did enable the privileges for the "Adminstrator or SomeGroup" ?
>> which needs to me done on ALL member servers.
>> I dont see any errors here.
>>
> If you are referring to SeDiskOperatorPrivilege, so yes:
> root at ostraaros:~# smbd -V
> Version 4.1.12-SerNet-Ubuntu-9.trusty
> root at ostraaros:~# net rpc rights list accounts -U administrator
> Enter administrator's password:
> BUILTIN\Print Operators
> No privileges assigned
>
> BUILTIN\Account Operators
> No privileges assigned
>
> BUILTIN\Backup Operators
> No privileges assigned
>
> BUILTIN\Server Operators
> No privileges assigned
>
> BUILTIN\Administrators
> SeMachineAccountPrivilege
> SeTakeOwnershipPrivilege
> SeBackupPrivilege
> SeRestorePrivilege
> SeRemoteShutdownPrivilege
> SePrintOperatorPrivilege
> SeAddUsersPrivilege
> SeDiskOperatorPrivilege
> SeSecurityPrivilege
> SeSystemtimePrivilege
> SeShutdownPrivilege
> SeDebugPrivilege
> SeSystemEnvironmentPrivilege
> SeSystemProfilePrivilege
> SeProfileSingleProcessPrivilege
> SeIncreaseBasePriorityPrivilege
> SeLoadDriverPrivilege
> SeCreatePagefilePrivilege
> SeIncreaseQuotaPrivilege
> SeChangeNotifyPrivilege
> SeUndockPrivilege
> SeManageVolumePrivilege
> SeImpersonatePrivilege
> SeCreateGlobalPrivilege
> SeEnableDelegationPrivilege
>
> Everyone
> No privileges assigned
>
> EXAMPLE\Domain Admins
> SeRestorePrivilege
> SeDiskOperatorPrivilege
>
> root at ostraaros:~#
>
>>>>>>> I don't have problems. As implied above; I have assigned uidNumber and
>>>>>>> gidNumber to all domain accounts, including the domain administrator
>>>>>>> account. And all groups as well, built-in or man made.
>> Im thinking here you did something wrong, or you assinged to an account which should not.
>>
>> https://wiki.samba.org/index.php/Using_RFC2307_on_a_Samba_DC
>> Using ADUC to set Unix Attributes on groups ..
>> It's not required to add users to the group in this tab! Winbind, sssd and nslcd retrieve the account membership from the Windows groups
>>
>>
>>>> root:x:0:0:root:/root:/bin/bash
>>>> ~ ~ ~ ~ ~ ~ ~ ~
>>>> root:*:10007:10000:root:/root:/bin/bash
>> will go give problems on the long run..
>> ( i know i tried something like this about 10 years ago. )
>>
>>
>>>> Comment from Rowland.
>>>> There is only one admin user on Unix, that is 'root' and root's id is
>>>> '0', so if you want the windows admin user 'Administrator' to do on Unix
>>>> what the Unix user 'root' can, then 'Administrator' must pretend to be
>>>> 'root', you do this by the use of smbmap.
>>>>
>> YES!!! thats correct. ... and for that you need to use the usermapping setting on a member server.
>>
> Se the elaboration above.
>
>> SO whats the problem besides, and this im guessing base on above.
>> 1) you need windows users in linux groups ?
> No.
>
>> 2) you need unix users in windows groups?
> No.
>
>> 3) you need to have windows users work with unix users
> Preferrably.
>
>> 4) did you set the privileges on the member server for groups which need it.
> Se above.
>
>> 5) you need to set the user mapping file.
> No. I don't.
>
>> 6) when all done, you need to setup your rights ( and share rights)
>> again.. since what you tried will mess up the rights in the long run.
> Both Share and NTFS rights are correct.
>
>> 7) remember ADDC samba is NOT member server Samba, 2 complete different things and setups.
>>
> This is a member server running Ubuntu 14.04 with Sernet Samba on top.
>
>> But,, its just a suggestion, you can go trie what you want but you will get the same advice from us.
>>
> I'm aware of that.
>
> Regards
> Davor
>
>> Louis
>>
>>
>>
>>
>>> -----Oorspronkelijk bericht-----
>>> Van: davortvusir at gmail.com
>>> [mailto:samba-bounces at lists.samba.org] Namens Davor Vusir
>>> Verzonden: maandag 27 oktober 2014 14:34
>>> Aan: samba at lists.samba.org
>>> Onderwerp: Re: [Samba] Samba4: "MYDOM\Administrator" quite
>>> useless on a member server?
>>>
>>> 2014-10-27 10:52 GMT+01:00 Rowland Penny <rowlandpenny at googlemail.com>:
>>>> On 27/10/14 08:07, Davor Vusir wrote:
>>>>> 2014-10-24 11:27 GMT+02:00 Rowland Penny
>>> <rowlandpenny at googlemail.com>:
>>>>>> On 23/10/14 21:16, Davor Vusir wrote:
>>>>>>> 2014-10-23 14:04 GMT+02:00 Rowland Penny
>>> <rowlandpenny at googlemail.com>:
>>>>>>>> On 23/10/14 12:22, ?icro MEGAS wrote:
>>>>>>>>> Hello list,
>>>>>>>>>
>>>>>>>>> my DC and member server is running Samba 4.1.12. The DC was
>>>>>>>>> provisioned
>>>>>>>>> with rfc2307 and NIS extensions. Through ADUC tool and the [UNIX
>>>>>>>>> Attribute]
>>>>>>>>> tab I assigned a uid to the AD user "testuser1" and I
>>> also assigned a
>>>>>>>>> gid to
>>>>>>>>> the AD group "Domain Users". The member server was configured
>>>>>>>>> according
>>>>>>>>> the
>>>>>>>>> official wiki of samba.org. Winbind was configured on the member
>>>>>>>>> server
>>>>>>>>> and
>>>>>>>>> /etc/nsswitch.conf was modified, too like that:
>>>>>>>>>
>>>>>>>>> passwd: compat winbind
>>>>>>>>> group: compat winbind
>>>>>>>>>
>>>>>>>>> My questions are:
>>>>>>>>>
>>>>>>>>> (1.) "wbinfo -p", "wbinfo -u" and "wbinfo -g" executed
>>> on the member
>>>>>>>>> server all are returning correct and expected results.
>> >From "wbinfo
>>>>>>>>> -u"
>>>>>>>>> and
>>>>>>>>> "wbinfo -g" I get all the available AD users+groups.
>> >From "getent
>>>>>>>>> passwd" I
>>>>>>>>> get only the AD users, for which a uid on the UNIX
>>> attribute exist, in
>>>>>>>>> that
>>>>>>>>> case "testuser1" is displayed correctly. But when I run
>>> "getent group"
>>>>>>>>> I
>>>>>>>>> don't get the group "Domain Users" although this group
>>> also has a gid
>>>>>>>>> assigned. The strange thing is that "getent group
>>> 'Domain Users'" or
>>>>>>>>> "getent
>>>>>>>>> group 10000" works fine though:
>>>>>>>>>
>>>>>>>>> [root at membersrv1:~$ getent group 'Domain Users'
>>>>>>>>> domain users:x:10000:
>>>>>>>>> [root at membersrv1:~$ getent group 10000
>>>>>>>>> domain users:x:10000:
>>>>>>>>>
>>>>>>>>> Why does "getent group" *NOT* returning the AD domain
>>> groups, that
>>>>>>>>> certainly have a GID assigned as UNIX attribute? I
>>> installed a new
>>>>>>>>> member
>>>>>>>>> server with samba 4.1.11/wheezy-backports and joined it
>>> to my DC. The
>>>>>>>>> same
>>>>>>>>> problem exists on that new member server. I don't get
>>> the AD groups
>>>>>>>>> displayed by command "getent group" but with " getent
>>> group 'Domain
>>>>>>>>> Users' "
>>>>>>>>> or " getent group 10000 " they are displayed correctly.
>>>>>>>>>
>>>>>>>>> Where is that issue related to?
>>>>>>>> It is related to a known problem, if indeed it is a
>>> problem, you will
>>>>>>>> have
>>>>>>>> to give **every** group a gidNumber to get 'getent
>>> group' to work like
>>>>>>>> 'getent paswd'. If I was you, I wouldn't worry about it,
>>> everything
>>>>>>>> else
>>>>>>>> seems to work.
>>>>>>>>
>>>>>>> Perhaps not anything to worry about. But isn't uid- and
>>> gidNumber to
>>>>>>> be considered the "bridge", in some sense, between the
>>> Windows-world
>>>>>>> and Linux-world? And winbind is the interpretator? Wouldn't it be
>>>>>>> better to advice to assign both uid- and gidNumbers to
>>> user accounts
>>>>>>> and gidNumbers to groups? For compatability sake?
>>>>>>
>>>>>> What you are saying is indeed true, but you only need to
>>> add uidNumber's
>>>>>> &
>>>>>> gidNumber's to users & groups that you want/need to be
>>> visible to Unix
>>>>>> and
>>>>>> you would also have to use the winbind 'ad' backend (other similar
>>>>>> programs
>>>>>> are available)
>>>>>>
>>>>>>>>> (2.) For my understanding please anyone explain to me.
>>> Every user or
>>>>>>>>> group
>>>>>>>>> I want to make usable on a member server *needs* to
>>> have a uid or gid
>>>>>>>>> assigned on the [UNIX attribute] tab, correct? On the
>>> other side, I
>>>>>>>>> was
>>>>>>>>> told
>>>>>>>>> *NEVER* ever assign a UNIX attribute UID to the
>>> "MYDOM\Administrator"
>>>>>>>>> account on the [UNIX attribute] tab in ADUC tool. So
>>> how should that
>>>>>>>>> special
>>>>>>>>> user "MYDOM\Administrator" be available for my member server? He
>>>>>>>>> cannot
>>>>>>>>> in
>>>>>>>>> my opinion, and so winbind never will be able to use him.
>>>>>>>>
>>>>>>>> Look. ignore what ever dev it was that told you not to
>>> use the smbmap,
>>>>>>>> just
>>>>>>>> use it, **everybody** who has any sense uses it.
>>>>>>>>
>>>>>>> I have stopped using usermapping because I get the
>>> following error in
>>>>>>> smbd.log:
>>>>>>>
>>>>>>> [2014/10/23 21:32:46.464772, 0]
>>>>>>> ../lib/util/become_daemon.c:136(daemon_ready)
>>>>>>> STATUS=daemon 'smbd' finished starting up and ready to serve
>>>>>>> connectionsFailed to fetch record!
>>>>>>> [2014/10/23 21:32:49.389720, 0]
>>>>>>> ../source3/smbd/uid.c:153(check_user_share_access)
>>>>>>> user root connection to home denied due to share security
>>>>>>> descriptor.
>>>>>>> [2014/10/23 21:32:49.475638, 0]
>>>>>>> ../source3/smbd/uid.c:153(check_user_share_access)
>>>>>>> user root connection to home denied due to share security
>>>>>>> descriptor.
>>>>>>>
>>>>>>> I also get access denied to the security tab in Computer
>>> Management
>>>>>>> MMC/Shared Folders/Shares/<ShareName>. Trying to have a peek at
>>>>>>> Computer Management MMC/Shared Folders/Sessions renders an access
>>>>>>> denied message box. Likewise for "Open Files". Commenting
>>> "username
>>>>>>> map" makes it all work again.
>>>>>>
>>>>>> I would think that you have other problems, I use smbmap
>>> without problem,
>>>>>> also there are probably quite a lot of other people using
>>> smbmap and I
>>>>>> have
>>>>>> never heard of the problems that you have posted.
>>>>>>
>>>>> I don't have problems. As implied above; I have assigned
>>> uidNumber and
>>>>> gidNumber to all domain accounts, including the domain administrator
>>>>> account. And all groups as well, built-in or man made.
>>>>>
>>>>> Some history:
>>>>> First create a directory and add it to the [share] in smb.conf.
>>>>> Nothing new here.
>>>>> root at ostraaros:~# ls -al /data/
>>>>> drwxr-xr-x 2 root root 4096 Oct 26 09:26 test2
>>>>>
>>>>> Start Computer Management MMC, open Shares and show Properties about
>>>>> the share gives me an access denied. But adding 'smbmap' to smb.conf
>>>>> allows me to view the properties and looks like this:
>>>>> Share-ACL:
>>>>> C:\Users\administrator>setacl -on \\ostraaros\test2 -ot shr
>>> -actn list
>>>>> \\ostraaros\test2
>>>>> DACL(not_protected):
>>>>> Everyone full allow no_inheritance
>>>>> SetACL finished successfully.
>>>>>
>>>>> And the NTFS ACL:
>>>>> C:\Users\administrator>setacl -on \\ostraaros\test2 -ot file -actn
>>>>> list \\ostraaros\test2
>>>>> DACL(not_protected):
>>>>> Unix User\root full allow no_inheritance
>>>>> Unix Group\root read_execute allow no_inheritance
>>>>> Everyone read_execute allow no_inheritance
>>>>> Creator Owner full allow
>>>>> container_inherit+object_inherit+inherit_only
>>>>> Creator Group read_execute allow
>>>>> container_inherit+object_inherit+inherit_only
>>>>> Everyone read_execute allow
>>>>> container_inherit+object_inherit+inherit_only
>>>>> SetACL finished successfully.
>>>>> C:\Users\administrator>
>>>>>
>>>>>
>>>> Two things from the above jump out at me, one you are trying
>>> to stop root
>>>> doing something, good luck with that on a Unix machine.
>>> secondly, you have a
>>>> user called 'root' and a group called 'root', don't know how
>>> you managed
>>>> that because it is not supposed to be possible (or allowed
>>> anyway), see
>>>> here:
>>> http://technet.microsoft.com/en-gb/library/cc783323%28v=ws.10%29.aspx
>>> It was not my intention to neither insult you nor offend you.
>>> My apoligies.
>>>
>>> I'm not trying to stop root from doing anything. I don't have an
>>> account named root in AD. Nor a group with that name. Commenting
>>> 'winbind use default domain = yes' makes it clearer. See listing
>>> below. The root account (Unix User\root) in the listing above is the
>>> root account on the Linux server (from /etc/passwd).
>>>
>>> root at ostraaros:~# getent passwd
>>> root:x:0:0:root Ostraaros:/root:/bin/bash
>>> daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
>>> ...
>>> ntp:x:111:121::/home/ntp:/bin/false
>>> dnsmasq:x:108:65534:dnsmasq,,,:/var/lib/misc:/bin/false
>>> EXAMPLE\administrator:*:10500:10513:Administrator:/data/home/ad
>>> ministrator:/bin/false
>>> EXAMPLE\davor:*:11105:10513:Davor Vusir:/data/home/davor:/bin/false
>>> EXAMPLE\dns-dc1:*:11123:10513:dns-DC1:/data/home/dns-dc1:/bin/false
>>> EXAMPLE\krbtgt:*:10502:10513:krbtgt:/data/home/krbtgt:/bin/false
>>> EXAMPLE\guest:*:10501:10514:Guest:/data/home/guest:/bin/false
>>>
>>> root at ostraaros:~# getent group
>>> root:x:0:
>>> ...
>>> libvirtd:x:120:admind,root
>>> ntp:x:121:
>>> EXAMPLE\allowed rodc password replication group:x:10571:
>>> EXAMPLE\enterprise read-only domain controllers:x:10498:
>>> EXAMPLE\denied rodc password replication group:x:10572:EXAMPLE\krbtgt
>>> EXAMPLE\read-only domain controllers:x:10521:
>>> EXAMPLE\group policy creator owners:x:10520:EXAMPLE\administrator
>>> EXAMPLE\ras and ias servers:x:10553:
>>> EXAMPLE\domain controllers:x:10516:
>>> EXAMPLE\enterprise admins:x:10519:EXAMPLE\administrator
>>> EXAMPLE\domain computers:x:10515:
>>> EXAMPLE\fileacc-common:x:11107:EXAMPLE\davor
>>> EXAMPLE\cert publishers:x:10517:
>>> EXAMPLE\dnsupdateproxy:x:11103:
>>> EXAMPLE\domain admins:x:10512:EXAMPLE\administrator
>>> EXAMPLE\domain guests:x:10514:
>>> EXAMPLE\schema admins:x:10518:EXAMPLE\administrator
>>> EXAMPLE\domain users:x:10513:
>>> EXAMPLE\fileacc-home:x:11106:EXAMPLE\davor
>>> EXAMPLE\dnsadmins:x:11102:
>>>
>>> And a directory listing:
>>> root at ostraaros:~# ls -al /data/
>>> total 48
>>> drwxr-xr-x 8 root root 4096
>>> Oct 26 09:26 .
>>> drwxr-xr-x 23 root root 4096
>>> Oct 14 21:08 ..
>>> drwxrwx---+ 24 EXAMPLE\administrator root 4096 Oct 5
>>> 17:31 common
>>> drwxrwx---+ 11 root users 4096
>>> Oct 2 06:40 home
>>> drwxrwx---+ 2 EXAMPLE\davor EXAMPLE\domain admins 4096 Aug 12
>>> 20:38 test
>>> drwxrwx---+ 2 EXAMPLE\administrator root 4096
>>> Oct 26 09:26 test2
>>> drwxr-xr-x 6 libvirt-qemu libvirtd 4096
>>> Jul 15 06:30 virt
>>> root at ostraaros:~#
>>>
>>>> Look under 'To create a user account on a local computer'
>>>>
>>>> You have also given the Unix user 'root' a uidNumber, I have
>>> never done
>>>> this, so I thought I would give it a try, I first had to
>>> create 'root' in AD
>>>> and then add the 'uidNumber', well yes it works, BUT I now
>>> have two 'root'
>>>> users:
>>>>
>>> The account root is from the Linux server. It is not a account in AD.
>>> See listing above.
>>>
>>>> rowland at ThinkPad ~ $ getent passwd
>>>> root:x:0:0:root:/root:/bin/bash
>>>> ~ ~ ~ ~ ~ ~ ~ ~
>>>> root:*:10007:10000:root:/root:/bin/bash
>>>>
>>>> Still think it is a good idea ??
>>>>
>>> Yes. I do.
>>>
>>> Regards
>>> Davor
>>>
>>>> Rowland
>>>>
>>>> Going now to delete the 'phantom' root user!!
>>>>
>>>>
>>>>
>>>> --
>>>> To unsubscribe from this list go to the following URL and read the
>>>> instructions: https://lists.samba.org/mailman/options/samba
>>> --
>>> To unsubscribe from this list go to the following URL and read the
>>> instructions: https://lists.samba.org/mailman/options/samba
>>>
>>>
>> --
>> To unsubscribe from this list go to the following URL and read the
>> instructions: https://lists.samba.org/mailman/options/samba
More information about the samba
mailing list