CIFS(Illumos|Solaris): Wie kickt man sofort(!) einen smb-user?

[shh]

Hallo,
ich habe hier ein Problem mit OmniOS, allerdings dürfte das auch allgemein für Solaris-Derivate gelten. Alles was ich im Netz finde hilft einfach nichts.

Man hat einen am Server eingeloggten Benutzer einer Win7-Rechners, der ein ZFS-share des CIFS-Servers benutzt.
Jetzt möchte man z.B.:
1. dem user mehr/weniger Rechte einräumen, indem man ihn zu einer zusätzlichen Gruppe hinzufügt, oder von vorherigen Gruppen entfernt:
usermod -G fsk16 bubi # hier: Bubi hat Geburtstag, und darf jetzt auch fsk16 anschaun
oder
2. einem "bösen" Benutzer sofort(!) den Zugriff entziehen, ohne dass das Einfluss auf die anderen Benutzer hat. Bsp.:
passwd bubi # Passwort ändern
smbadm disable-user bubi # user deaktivieren

Problem:
In beiden Fällen kommen Änderungen nicht sofort beim Client an. Der Nutzer hat "ewig" (wie lange eigentlich?) die alten eingeräumten Rechte, sieht nicht mehr/weniger (1.) und hat auch weiter den vorherigen Zugriff, selbst wenn man dem bösen user von (2.) das Passwort sperrt.

smbutil logout bubi@SERVER bringt nichts per SSH, weil man zuerst so eingeloggt haben muss, nicht etwa via Windows-Netzwerk.
smbadm disable-user bubi deaktiviert das smb-Passwort, kommt aber nicht sofort an
svcadm restart smb/server killt den Server, schmeißt damit aber auch gültige Benutzer raus, bricht streams ab etc. "refresh" bringt auch nichts, wenn man zB das Passwort geändert hat
Am Client hilft für die Aktualisierung der Zugriffsrechte schließlich ein Abmelden des Win7-Nutzers, oder auch ein de/reaktivieren der Netzwerkkarte. Aber, das soll ja nicht nötig sein. Änderung am Server sollten "sofort" beim Client Änderungen bewirken.

Ideen?

 

[gea]

Neben einem Service Restart könnte das über Windows und Computer Management gehen
- Computer Management an einem Windows Rechner starten
- Computer Management mit OmniOS verbinden (als Benutzer der in der SMB Admingruppe ist)
- Shares - disconnerct

 

[shh]

Hmm, ich versteh nicht recht wie das gehen soll.
Computer Management (=Computerverwaltung?) fragt überhaupt nicht nach login+passwort. D.h. ich kann mich da nur als "kastrierter" Nutzer verbinden - und dann natürlich nichts aktualisieren oder disconnecten.
Was ist eine "SMB Admingruppe"?
Bisher habe ich Admin-Aufgaben immer via SSH als root getätigt.
Und, mit dem disconnect via Computerverwaltung wird er vermutlich _alle_ sessions killen, nicht nur bestimmte. Richtig?

Service Restart (svcadm restart smb/server) killt wie gesagt auch andere sessions.
Gibt es eine Möglichkeit, am Server
- einzelne sessions vom smbd anzeigen zu lassen = welche Clients sind verbunden, mit welchem login-Namen
- einzelne sessions zu kicken/aktualisieren?

Nur zur Ergänzung für Mitleser. Aktualisiert bekommt man das *am Client* - was ich eigentlich verhindern wollte - auch so:
- DHCP-Dienst restarten, um die alte session zu löschen. Dabei ist kein erneutes login+Passwort nötig und nach F5 zeigt der Explorer die neuen Ordner an.
- net use * /delete auf dem Client anwenden, damit sich der anschließend (nach Explorer schließen und auf timeout warten) wieder neu anmelden kann.

 

[fdsonne]

gea meint, wenn du in einem Windows via "mmc" das Computermanegment Snapin hinzufügst, kannst du als Remote Server die IP (oder den Namen) deines Storage Systems eintragen. Damit kannst du via GUI bspw. Ordnerrechte Setzen oder aber auch bestehende Sessions ausloggen (via Klick)
Das Problem dabei ist, das du bei dieser Methode keine Möglichkeit hast, einen Useraccount zu hinterlegen. Sprich er nutzt für den Connect zum Management den User (mit den entsprechenden Rechten) der an deinem Windows PC angemeldet ist.
Das kann man aber umgehen indem man sich mit einem Account anmeldet, der entsprechende Admin Rechte auf dem Storagesystem hat. Ist das ganze noch an ein AD gekoppelt, muss dazu nichtmal getrickst werden. Ist kein AD vorhanden, musst du einen lokalen Useraccount auf einem (als admin Terminal in dem Fall dienenden) Windows Client erstellen. Wichtig dabei ist, Username + PW müssen exakt dem entsprechen wie dem admin/root User, der entsprechende Rechte auf dem Storage System hat. Mit diesem Account führst du dann die Microsoft Management Console aus und holst dir das Computerverwaltungs-SnapIn respektive das Storage SnapIn. -> dann klappt auch der Connect mit entsprechenden Rechten.

Normal (in der Windows Welt) greift sowas binnen weniger Sekunden. Sprich ausgelogte Sessions sind auch sofort weg!
Was nicht so ohne weiteres greift, wenn du mit AD Usern hantierst, die in AD Gruppen hin und her geschubst werden -> für das wirken neuer AD Gruppenzuordnungen ist idR eine Neuanmeldung am Client notwendig! Aber auch hier gilt, verbote auf entsprechende Order schlagen wieder sofort durch -> man sieht aber eben neue, vormals verbotene Ordner erst nach der Neuanmeldung am Client!

 

[shh]

Vielen Dank für die Erklärungen!
Allerdings klappt das hier immer noch nicht. Das mit der Computerverwaltung-Fernsteuerung ist mir völlig neu, deshalb weiß ich jetzt nicht, wo mein Fehler liegt.
Total ärgerlich ist auch, dass man für die Fernverwaltung scheinbar keinen anderen Usernamen angeben kann.

Ich habe am Win7-Client einen extra Benutzer "root" mit selbem Passwort wie auf dem Server erstellt. Dabei gingen die SMB-shares im Explorer *sofort*, ohne, dass ich mich noch als root noch am Server authentifizieren musste. Auch mit *allen* Ordnern sichtbar, wie es für root sein sollte. D.h. der smbd lässt mich zumindest als client mit vollen Rechten zu.
In der mmc kann ich mich mit dem account auch mit meinem Server verbinden. Dabei sehe ich aber nicht mehr, als ein anderer User.
- mmc als Administrator gestartet
- Computerverwaltung hinzugefügt, anderer Server
Hmm.
Shares und Benutzer des Servers kann ich mir ansehen.
Clientverbindungen sind aber alle 0, und auf "Sitzungen" (und vieles andere) habe ich auch keinen Zugriff.

Hab ich vergessen, am Server den root für smbd-admin-Aufgaben freizugeben? Sollte root nicht von Haus aus alles können?

Bei den idmap hab ich (relevant) nur:
wingroup:Power Users@BUILTIN => unixgroup:staff
Die "Administratoren" haben root scheinbar nicht als member?
administrators (Members can fully administer the computer/domain) S-1-5-32-544 No members
backup operators (Members can bypass file security to back up files) S-1-5-32-551 No members
power users (Members can share directories) S-1-5-32-547 No members

NACHTRAG:
Sorry, hab's jetzt rausgekriegt. Wenn man Fragen ausformuliert wird einem oft dann erst klar, was eigentlich gefehlt hat.
Lösung war:
smbadm add-member -m root administrators

Aber die mmc OHNE einen extra root-account auf meinem "Fernsteuer"-Client geht nicht, oder?
AD hab ich hier nicht, nur workgroup-mode.

 

[fdsonne]

Ohne wird nur dann funktionieren, wenn du eben entweder als Mainuser Account auf der Windows Kiste einen User verwendest, der root heist (und das gleiche PW hat) Oder aber, wenn du den Useraccount, so wie er auf dem Windows PC heist (+ Kennwort) eben analog wie oben berechtigst, diese Aufgabem auf dem Storage Server zu übernehmen.
Beides ist machbar...

Ich finde aber die Lösung mit dem externem Root User Account auf der Windows Kiste gar nicht mal soooo schlimm.
Denn das MMC Fenster lässt sich speichern, bspw. auf den Desktop. Wenn du das machst, kannst du bspw. mit gedrückter "Shift" Taste und gleichzeitigem Rechtsklick auf eben jene Verknüpfung ein Menü einblenden, was sich "als Anderer Benutzer öffnen" (oder sinngemäß) schimpft. -> Machst du das, bekommst du ne default Windows Anmeldemaske -> dort hämmerst du den dann root + entsprechendes PW ein und öffnest die Management Console (inkl. der eingeklinkten SnapIns) unter dem Kontext des Root Useraccounts.
Fazit: kein umständliches und vollständiges An/Abmelden notwendig. Und du bekommst ohne großen Aufwand deine Console auf. Viel einfacher wirds wohl nicht werden ohne AD

 

[shh]

Danke nochmal! Ist aber trotzdem total unverständlich dass die mmc keine beliebigen login+passwd für externe Computer zulässt. Das ist ja quasi immer so, dass externe Computer ein anderes login+passwd haben. Sinn?? Wie kann man nur sowas programmieren?

Problem mit der mmc: Die friert hier alle 5sek ein und fängt dann wieder von vorne an, die sessions zu suchen. Wobei nie alle sessions angezeigt werden.
Netzwerk-Auslastung ist aber nicht voll, auch nicht CPU-Auslastung etc. So bringt das natürlich auch nichts.

Wie man die smb-sessions am Unix-Rechner anzeigen lassen kann, weiß (noch) keiner, oder?

 

[fdsonne]

Sinn? Das ist ein Tool, was aus der Serverwelt von Microsoft kommt und für dies und jenes auch auf Clients abgestellt wurde...
Server = AD Da brauch es keinem User + PW Fenster, da hast du ein zentrales AD.
Das gilt auch zur Clientverwaltung. Denn AD Member Clients werden dann über global berechtigte Admin Account gesteuert und entsprechend angesprochen -> mit entsprechenden Berechtigungen.

Dezentrale Userverwaltung nutzt im Business doch heute kein Mensch mehr

Warum es bei dir aber immer zu Abbrüchen kommt, kann ich dir allerdings nicht sagen. Eventuell ein Versionproblem könnte ich mir noch vorstellen... Hast du die Möglichkeit mal mit nem anderen Client Windows zu testen?

 

[gea]

Danke nochmal! Ist aber trotzdem total unverständlich dass die mmc keine beliebigen login+passwd für externe Computer zulässt. Das ist ja quasi immer so, dass externe Computer ein anderes login+passwd haben. Sinn?? Wie kann man nur sowas programmieren?

Problem mit der mmc: Die friert hier alle 5sek ein und fängt dann wieder von vorne an, die sessions zu suchen. Wobei nie alle sessions angezeigt werden.
Netzwerk-Auslastung ist aber nicht voll, auch nicht CPU-Auslastung etc. So bringt das natürlich auch nichts.

Wie man die smb-sessions am Unix-Rechner anzeigen lassen kann, weiß (noch) keiner, oder?

zu dem Login:
Habs schon eine Weile nicht gebraucht, aber es sollte ohne AD so gehen:
-An OmniOS einen user anlegen z.B. admin und diesen user in die OmniOS SMB Gruppe "Administrators" aufnehmen. -Dann per SMB als admin an einem share anmelden.
-Computermanagement sollte dann diesen Account benutzen


Zu SMB sessions unter OmniOS anzeigen:
Das geht wohl nur wenn man SAMBA einsetzt. Hier ist auch ein konzeptioneller Unterschied von SAMBA und Solaris CIFS. SAMBA soll einem PC user Zugriff auf einen Unix Server bieten - Die Verwaltung erfolgt auf Unix und das was der PC User sieht ist ein Unix Server mit Unix permissiones und Unix UID/GID.

Solaris/OmniOS CIFS geht da einen anderen Weg. Entwicklungsziel von Sun war ein SMB Server der von Windows aus administriert wird und der sich von aussen so verhält wie ein Windows 2003 Server inkl Windows ACL, Windows SID und Management über die Windows Management Console. Für einige Unix Admins mag das ein Nachteil sein. Ich bin froh darüber bringt es doch einen "fast echten" Windows Server mit Unix Stabilität und ZFS.