Bug #14322
openRemote OmniOS SMB user/group management via Windows computermanagement not working
0%
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
Updated by Gordon Ross 6 months ago
- Category set to cifs - CIFS server and client
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.
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
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.
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