RPvs> On Tue, 22 May 2018 09:08:31 -0700 RPvs> Gregory Sloop via samba <samba at lists.samba.org> 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. RPvs> 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]>> 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 domain RPvs> 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.] Are we on the same page now? :) --- 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. 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.] 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. 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 [ipv4:10.115.1.231:445] [2018/05/21 19:03:39.828973, 4] ../auth/auth_log.c:220(log_json) JSON Authorization: {"timestamp": "2018-05-21T19:03:39.828933-0700", "type": "Authorization", "Authorization": {"version": {"major": 1, "minor": 0}, "localAddress": "ipv4:10.115.1.231:445", "remoteAddress": "ipv4:10.115.1.154:49441", "serviceDescription": "DCE/RPC", "authType": "ncacn_np", "domain": "AD", "account": "Administrator", "sid": "S-1-5-21-787471243-3174888660-1208226227-500", "logonServer": "SNCC-ADC1", "transportProtection": "SMB", "accountFlags": "0x00000010"}} [2018/05/21 19:03:39.829092, 3] ../auth/auth_log.c:139(get_auth_event_server) get_auth_event_server: Failed to find 'auth_event' registered on the message bus to send JSON authentication events to: NT_STATUS_OBJECT_NAME_NOT_FOUND [2018/05/21 19:03:39.835556, 3] ../source4/smbd/service_stream.c:65(stream_terminate_connection) Terminating connection - 'dcesrv: NT_STATUS_CONNECTION_DISCONNECTED' [2018/05/21 19:03:39.835706, 3] ../source4/smbd/process_single.c:114(single_terminate) single_terminate: reason[dcesrv: NT_STATUS_CONNECTION_DISCONNECTED] [2018/05/21 19:04:07.594760, 3] ../source4/smbd/service_stream.c:65(stream_terminate_connection) [2018/05/21 19:04:07.595045, 3] ../source4/smbd/service_stream.c:65(stream_terminate_connection) [2018/05/21 19:04:07.595251, 3] ../source4/smbd/service_stream.c:65(stream_terminate_connection) [2018/05/21 19:04:07.595416, 3] ../source4/smbd/service_stream.c:65(stream_terminate_connection) Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET' [2018/05/21 19:04:07.595741, 2] ../source4/smbd/process_standard.c:473(standard_terminate) Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET' [2018/05/21 19:04:07.596010, 2] ../source4/smbd/process_standard.c:473(standard_terminate) Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET' [2018/05/21 19:04:07.596253, 2] ../source4/smbd/process_standard.c:473(standard_terminate) Terminating connection - 'ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET' [2018/05/21 19:04:07.596487, 2] ../source4/smbd/process_standard.c:473(standard_terminate) standard_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET] standard_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET] standard_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET] standard_terminate: reason[ldapsrv_call_loop: tstream_read_pdu_blob_recv() - NT_STATUS_CONNECTION_RESET] [2018/05/21 19:04:07.611197, 2] ../source4/smbd/process_standard.c:157(standard_child_pipe_handler) Child 28639 () exited with status 0 [2018/05/21 19:04:07.611422, 2] ../source4/smbd/process_standard.c:157(standard_child_pipe_handler) Child 28630 () exited with status 0 [2018/05/21 19:04:07.611573, 2] ../source4/smbd/process_standard.c:157(standard_child_pipe_handler) Child 28602 () exited with status 0 [2018/05/21 19:04:07.611724, 2] ../source4/smbd/process_standard.c:157(standard_child_pipe_handler) Child 28609 () exited with status 0 --- Again - much thanks for the help so far. Hopefully I can nail this down. -Greg
On Tue, 22 May 2018 12:26:26 -0700 Gregory Sloop via samba <samba at lists.samba.org> wrote:> > > RPvs> On Tue, 22 May 2018 09:08:31 -0700 > RPvs> Gregory Sloop via samba <samba at lists.samba.org> 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. > RPvs> > > 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 Unix users. 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 hostThis 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. Rowland
>> >> 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. >> RPvs>>> 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]RPvs> There is a big problem with that, to change the ACLs on a share (a RPvs> better name for the security tab would be 'NTFS permissions'), the user RPvs> doing the changes must be known to the OS. In your case, you are using RPvs> 'Administrator' and on a DC, this is automatic, but on a Unix domain RPvs> member (or standalone server) you need to add a 'username map' line to RPvs> smb.conf and map 'Administrator' to 'root' RPvs> But I'm not doing anything on any file system. I'm using RSAT against the Ubuntu Samba AD DC ONLY. I get that once I start setting share permissions, we'll be mapping "unix" users to AD users, but that is not in the mix now. I've not attempted to join the NAS, I'm not talking about anything on the NAS. I only mention the end-point in case it matters. See following... RPvs> I feel that you are in a chicken or egg situation here, you want to RPvs> make the NAS into a Unix domain member by using a Domain user. RPvs> If you can alter the smb.conf on the NAS correctly, it will become a RPvs> Unix domain member and you will then be able to use the AD users as RPvs> Unix users. RPvs> It may be that you are trying to admin the NAS via a gui, if so, does RPvs> this gui allow you to make the required changes ? RPvs> What version of Samba is the NAS running ? RPvs> Can you manually change the smb.conf ? I'm not doing any admin on anything other than the Samba AD DC using RSAT. [Not that it matters yet, but the FreeNAS version I'm running has Samba 4.7.0 on it. But again, we've not gotten to any point where the NAS is talking to the AD DC, or sharing files. I'm doing the work (following the NAS docs) to get a computer and user account setup so I can work on configuring the NAS as the next step.]>> Are we on the same page now? :)RPvs> No, I don't think we are, I am on the page that knows how to set up a RPvs> 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.RPvs> I would have do it a bit differently, provisioned the DC, joined the RPvs> Win7 to the domain and then installed RSAT. Which is where we are, except I've not joined the station I'm running RSAT from to the domain. But I'm launching the RSAT in a way that allows it to see and admin the AD DC. [If we really think joining the domain is why the RSAT station is barfing, while using RSAT, I can do that. It doesn't look that way to me, but I suppose it's possible.] RPvs> And if you didn't want to throw any Unix machines into the mix, this is RPvs> as far as you need to go. Again, I get that we'll get into Unix/AD user mix once we get to actually sharing files and setting shared file permissions. But, again, I'm simply trying to configure the AD *Computer* account via RSAT. Like this: Open RSAT. [AD Users and Computers] Go to the AD Domain, expand it. View | Advanced features Locate the AD Computer account I've already created. Right Click | Properties Try to move to the "Security" tab. And it hangs.>> 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.RPvs> Can you run 'getent' on the NAS, if so, does 'getent passwd anADuser' RPvs> produce any output, until it does, you will not get anywhere. RPvs> When you get right down to it, a NAS is just a Unix machine running RPvs> 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 hostRPvs> This seems to show 'Administrator is known to the NAS, but is being RPvs> rejected, this is possibly because the SID isn't the same as the one RPvs> for the NAS. It should actually show 'Administrator' being mapped to RPvs> root on the NAS. There is no NAS talking to anything yet! This is the RSAT box [10.55.1.154] talking to the AD DC [10.115.1.131] This is the RSAT querying and displaying the details one would see using the RSAT Users and Computers tool/add-in. [Perhaps we can get around this using samba-tool instead of RSAT, but I didn't think Samba-tool could create computer accounts - only user accounts. I'm certainly not aware of a way to create Computer accounts with a CLI samba tool.]