Re: [Samba] RSAT Hang
- Date: Tue, 22 May 2018 21:07:54 +0100
- From: Rowland Penny via samba <samba@xxxxxxxxxxxxxxx>
- Subject: Re: [Samba] RSAT Hang
On Tue, 22 May 2018 12:26:26 -0700
Gregory Sloop via samba <samba@xxxxxxxxxxxxxxx> wrote:
> RPvs> On Tue, 22 May 2018 09:08:31 -0700
> RPvs> Gregory Sloop via samba <samba@xxxxxxxxxxxxxxx> wrote:
> >> I was under the impression that during provision that the
> >> Administrator account got all the domain [and other] "root" privs
> >> by default. If that's the case, why doesn't Administrator have the
> >> privs we'd expect? [Perhaps I misunderstand what Administrator
> >> starts with after an initial provision.]
> RPvs> Administrator doesn't get any privileges normally, but it does
> RPvs> inherit all the 'Administrators' group privileges, but even this
> RPvs> group doesn't get them all AND they only apply to the DC.
> RPvs> You need to create them on each Unix machine.
> Yeah, I get that too. But since I'm simply doing user/computer
> maintenance in RSAT [in the AD], then Administrator _should_ have the
> correct privs to do what's required, right?
> Obviously, the "Administrator" account won't have any file-system
> privs etc, unless properly granted. But I'm not [at least as far as I
> know] doing any changes to the filesystem or files. I'm simply trying
> to add/veiw/change AD attributes. [i.e. Create/View/Change attributes
> in a user/computer in Active Directory]
There is a big problem with that, to change the ACLs on a share (a
better name for the security tab would be 'NTFS permissions'), the user
doing the changes must be known to the OS. In your case, you are using
'Administrator' and on a DC, this is automatic, but on a Unix domain
member (or standalone server) you need to add a 'username map' line to
smb.conf and map 'Administrator' to 'root'
> >> As to your prior message - the FreeNAS box isn't part of the setup
> >> yet. I'm just trying to get the user and computer accounts I'll
> >> need to join the NAS to AD ready.
> RPvs> If the NAS isn't part of a domain, it isn't like to know who a
> RPvs> domain user or group is, is it ;-)
> Correct. But I'm simply trying to view a RSAT created user and/or
> computer account and view the "security" tab when RSAT hangs. [I
> can't begin to handle joining the NAS until I have a properly
> configured user and computer account in AD. And these RSAT steps are
> pre-reqs for that.]
I feel that you are in a chicken or egg situation here, you want to
make the NAS into a Unix domain member by using a Domain user.
If you can alter the smb.conf on the NAS correctly, it will become a
Unix domain member and you will then be able to use the AD users as
It may be that you are trying to admin the NAS via a gui, if so, does
this gui allow you to make the required changes ?
What version of Samba is the NAS running ?
Can you manually change the smb.conf ?
> Are we on the same page now? :)
No, I don't think we are, I am on the page that knows how to set up a
DC and then join a computer as a Unix domain member ;-)
> If not, let me go back and restate, briefly, the root problem.
> Provisioned a *new* AD domain using Ubuntu 18.04 packaged Samba. [Not
> an AD join.] Took a Win7 machine, installed RSAT on it [but didn't
> join it to the domain.] Pointed MSC at the domain.
> Add in the user/computer RSAT tool.
I would have do it a bit differently, provisioned the DC, joined the
Win7 to the domain and then installed RSAT.
> At this point I can view the AD tree [for users/computers].
> I can see in the Samba logs, the RSAT tool querying AD, and getting
> answers. I can create users and computers fine. [And see that happen
> in Samba logging.]
And if you didn't want to throw any Unix machines into the mix, this is
as far as you need to go.
> In the setup steps for the NAS, I'm instructed to modify a setting on
> the "security" tab in RSAT for the computer account [which I created
> above] When I try to view the "security" tab of a user or computer
> object, RSAT hangs.
Can you run 'getent' on the NAS, if so, does 'getent passwd anADuser'
produce any output, until it does, you will not get anywhere.
When you get right down to it, a NAS is just a Unix machine running
Samba, just like the computer I am typing this on.
> This is a Log 5 of the relevant logs, when that happens.
> [2018/05/21 19:03:39.828780,
> 4] ../auth/auth_log.c:860(log_successful_authz_event_human_readable)
> Successful AuthZ: [DCE/RPC,ncacn_np] user [AD]\[Administrator]
> [S-1-5-21-787471243-3174888660-1208226227-500] at [Mon, 21 May 2018
> 19:03:39.828768 PDT] Remote host [ipv4:10.115.1.154:49441] local host
This seems to show 'Administrator is known to the NAS, but is being
rejected, this is possibly because the SID isn't the same as the one
for the NAS. It should actually show 'Administrator' being mapped to
root on the NAS.
To unsubscribe from this list go to the following URL and read the