Project

General

Profile

Actions

Bug #14322

open

Remote OmniOS SMB user/group management via Windows computermanagement not working

Added by Guenther Alka 7 months ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
cifs - CIFS server and client
Start date:
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
Gerrit CR:

Description

I have problems using Windows computermanagement to edit groups and users remotely.
What I have done (current Windows 10 Pro, OmniOS 151038 lts, 151040)

1. On OmniOS I added root to SMB group administrators

2.) Then I mapped a shared filesysem ex to z: as user root with the option "different user" and save pw
user: OmniOS-ip\root

3. I started Computermanagent on Windows.
With a mouse right-click on Computermanagement I connected the ip of OmniOS

i got an error that the computer could not be connected.
After I retried, it worked.

4. I was able to list/add/rename groups.
When I tried to add members via advanced > search, i got a login screen where I readded root credidentials, but no success (no users listed, only groups)

5. I was able to list users but could not add or rename.

As remote computermagent is the main method for local SMB server management this should work

gea

Actions #1

Updated by Gordon Ross 6 months ago

  • Category set to cifs - CIFS server and client
Actions #2

Updated by Gordon Ross 5 months ago

If you're doing this from a Windows client, you need to use some care about which identity will be used to connect to the SMB server. Windows can be a bit surprising here, not necessarily using the identity you might think it should. You can confirm that with a quick "mdb -k" session (use "::smblist" and look at who is really connected).

Cautions: When you're logged onto a Windows client that's a domain member, the client appears to always try your domain account first when connecting to servers (regardless what you put in "map share" and "connect as a different user").
When logged on as a local (not domain) user, Windows appears to try your logged on account first.
With the "IPC$" share used for MMC, these logons will generally pass, even though you might have preferred that they failed and gave you a chance to specify different credentials.
Usually if you have a mapped drive connected to some server first, then access to the "IPC$" share (eg. for MMC) will use those same credentials.
Hope that helps.

Actions #3

Updated by Guenther Alka 5 months ago

Problem happens as local user root, no AD involved

::smbuser

USER UID SSNID ACCOUNT
fffffe118826f648 1 1ee480c599e NAS\root

Actions #4

Updated by Gordon Ross about 1 month ago

Can you get the output of "::smbuser -v" for that user?
In particular, I'd like to see the user flags.

Actions #5

Updated by Guenther Alka about 1 month ago

::smbuser -v

SMB user information (fffffe11a3599b48):
UID: 1
SSNID: 1ee6373549f
State: 1 (LOGGED_ON)
Flags: 0x00000010 <ADMIN>
Privileges: 0x00800300 <SECURITY,TAKE_OWNER,CHANGE_NOTIFY>
Credential: fffffe118143de90
Reference Count: 2
User Account: NAS\root

Actions

Also available in: Atom PDF