• Apfeltalk ändert einen Teil seiner Allgemeinen Geschäftsbedingungen (AGB), das Löschen von Useraccounts betreffend.
    Näheres könnt Ihr hier nachlesen: AGB-Änderung
  • Viele hassen ihn, manche schwören auf ihn, wir aber möchten unbedingt sehen, welche Bilder Ihr vor Eurem geistigen Auge bzw. vor der Linse Eures iPhone oder iPad sehen könnt, wenn Ihr dieses Wort hört oder lest. Macht mit und beteiligt Euch an unserem Frühjahrsputz ---> Klick

Administratornamen ändern???

Alejandro

Transparent von Croncels
Registriert
08.10.05
Beiträge
306
Guten abend,
ich möchte gerne den Kurznamen meines Administratorkonto umbenennen. Habe bereits die Mac- Hilfe konsultiert, leider aber ohne passendes Ergebnis. Ist das Umbenennen eigentlich möglich, ohne OS X neu aufzusetzen? Schön wäre das ja... Ich hoffe, jemand da draußen weiß wie´s geht. Danke euch...
 

MacApple

Schöner von Bath
Registriert
05.01.04
Beiträge
3.652
Ja, das geht. Die sicherste Methode ist, einen neuen User mit Administrator-Rechten anlegen, eventuell noch benötigte Daten vom alten User-Ordner in den neuen kopieren und dann den alten User löschen.
Nur was für Leute, die sich damit auskennen, ist das Ändern des Kurznamens über den NetInfo-Manager. Wer dabei etwas vergisst, hat eventuell dann plötzlich gar keinen Administrator mehr.

MacApple
 

commander

Baldwins roter Pepping
Unvergessen
Registriert
25.02.04
Beiträge
3.206
Dem Kopieren der Dateien muss aber auch ein chown folgen, sonst kanns böse in die Hose gehen:

Die UID eines jeden Benutzers ist einzigartig, und nur für diesen User sind die Rechte garantiert - ein anderer Admin-User kann nur auf die für die Admin-Gruppe freigegebene Dateien zugreifen. In den meisten Fällen mag das funktionieren, aber für jemanden ohne profunde Unix-Ahnung würd ich das nicht empfehlen - kann dazu führen, daß der Anwender gewissen Dinge nicht mehr machen kann.

Eine Frage: Warum willst Du denn den Kurznamen ändern?

Gruß,

.commander

Den Displaynamen kann man ja ganz einfach ändern
 

mullzk

Linsenhofener Sämling
Registriert
04.01.04
Beiträge
2.529
commander schrieb:
Dem Kopieren der Dateien muss aber auch ein chown folgen, sonst kanns böse in die Hose gehen
jein, kommt drauf an von wo aus man kopiert. Wenn du im Finder als User B eingeloggt bist und etwas aus dem Verzeichnis und mit den Eigentumsrechten von User A kopierst, übernimmt es automatisch die Rechte von User B (zumindest wenn man sich für den Kopiervorgang authentifizieren muss), ein chown ist daher unnötig (allerdings schadet es auch nie).

Das Erstellen eines neuen Users und das Verschieben von den Daten des alten Users ins neue eigene Homeverzeichnis ist die einzig sichere Art. Suche mal ein bisschen hier auf AT und schau dir an, wieviele sich mit dem Weg übers Netinfo das gesamte System zerschossen haben - du willst ja wohl nicht auch zu diesen gehören ;)
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
Alejandro schrieb:
Guten abend,
ich möchte gerne den Kurznamen meines Administratorkonto umbenennen. Habe bereits die Mac- Hilfe konsultiert, leider aber ohne passendes Ergebnis. Ist das Umbenennen eigentlich möglich, ohne OS X neu aufzusetzen? Schön wäre das ja... Ich hoffe, jemand da draußen weiß wie´s geht. Danke euch...

Apple rät ausdrücklich davon ab das zu tun.
(Weil man sein System mit NetInfo *wirklich* mit zwei Mausklicks unbenutzbar machen kann - wenn man nicht den nötigen Hintergrund hat, das da drin zu verstehen.)
Und sei gewarnt - hüte dich vor den im Netz kursierenden "Anleitungen" dazu. Da hab ich (neben vielem richtigen natürlich) schon Dinge gelesen....eieiei...

Aber da du's vermutlich ohnehin probierst und das mit dem Umkopieren des Benutzerordners *nicht* die eleganteste Lösung ist (!), steck ich dir was. Aber vertue dich BLOSS nicht!

Leg einen zweiten und einen provisorischen dritten (!) Admin an. Den einen benennst du nach deinem Wunschnamen, den anderen von mir aus WinniePuuh.
Wenn du schon hier bist - schalte den "schnellen Benutzerwechsel" und die "automatische Anmeldung" unbedingt ab!
Auch ein evtl. aktives FileVault unbedingt ausschalten.
Ausserdem musst du sämtliche Sharing-Dienste beenden, bevor du loslegst.

Als dieser 'Winnie' meldest du dich dann neu an.
Dort öffnest du den NetInfo Manager und machst exakt das:

1) Authentifizieren natürlich. Im Menü "Sicherheit". Oder das Vorhängeschloss...sollte dir kaum neu sein.

2) Du siehst in der mittleren Spalte ganz unten den Punkt 'users'. Da gehst du drauf und rechts siehst du alle Nutzer, die es im System gibt. (Jaja. Ich weiss. Das sind viel mehr, als du eigentlich erwartet hast...passt schon. :) )

Suche deinen *alten* Namen und markiere ihn, daraufhin erscheinen unten alle Infos dazu.
Interessant sind nur die Zeilen 'uid' und 'gid'. Üblicherweise sind diese Zahlen ohnehin identisch. Vermutlich steht da '501'. Richtig?
Egal, diese Werte brauchst du später. Beide. Notieren, wenn du schlecht bei Gedächtnis bist.

3) Diese alten Werte änderst du nun.
Wenn der 'gid'-Wert bei dir noch '20' sein sollte, bleibt dieser überall unverändert. Dann ist nur die 'uid' für dich von Belang. Das ist bei Systemen so, die noch aus Jaguar-Zeiten stammen. Wäre völlig ok, keine Sorge.
Wenn beide Werte aber identisch sind, musst du auch beide synchron ändern.

Einfach die entsprechenden Felder doppelklicken und eine noch freie Zahl eintragen. Welche, ist eigentlich egal, nur *frei* muss sie sein. Ich empfehle dir zB die '9999'. So viele Accounts und Gruppen dürfte es auf deiner Kiste ganz sicher noch nicht gegeben haben, das passt schon...
Die Änderungen musst du jedesmal bestätigen, sobald du das Feld verlassen willst.

4) Jetzt gehst du oben in der mittleren Spalte auf den Eintrag 'groups'.

Wenn wie gewohnt deine beiden Zahlen gleich waren, dann findest du auch hier deinen alten Benutzernamen. Auswählen und unten findest du wieder eine Zeile mit 'gid'. Auch hier trägst du deine fiktive Nummer von eben ein und bestätigst.

(Falls deine beiden Zahlen *nicht* identisch gewesen sein sollten, und bei gid stand vorher die '20', fällt dieser Punkt 4 ersatzlos weg.)

5) Jetzt machst du genau das gleiche Spiel mit deinem *neuen* Wunschnamen. (Auch diese Werte merken.)
Dem verpasst du jetzt in genau den gleichen 3 Feldern einfach die Nummern, die dein alter Account vorher hatte. Wenn du alle 3 ausgefüllt hast, kommt der letzte Schritt in NetInfo - nicht vergessen:

6) Gehe erneut auf den alten Account und gib ihm (wieder drei mal) genau die Nummern, die der andere gerade eben noch hatte. (Sonst gibts später Zoff, wenn du ihn löschen willst...)
Dann kannst du das Programm schliessen.

7) Jetzt der finale Streich:
Du öffnest im Finder den Ordner /Benutzer (bzw. /Users)

Dort findest du die drei Admin-Ordner. Den Ordner deines neuen Wunschnamens benennst du provisorisch um. Den alten Ordner benennst du ebenfalls um - mit dem *exakten* neuen Namen (Kleinschreibung beachten!). Und den anderen erneut, so dass beide die Plätze getauscht haben. Andere Änderungen nimmst du *nicht* vor.

(Arbeite bei diesem Tausch *nicht* mit kopieren, sonst ändern sich die Rechte!)

8) Was dein Rechner nun braucht, ist ein Neustart. Danach solltest du dich bereits unter neuem Namen anmelden können und problemlos all deine Dateien finden.

Bevor du nun aber anfängst, die beiden überflüssig gewordenen Admins zu löschen, gehst du erst *sämtliche* Einstellungen durch, wo du Passwörter vergeben kannst und änderst sie probehalber mindestens ein mal ab, und zwar überall:

- Systemeinstellungen -> Benutzer

- Schlüsselbund (trotz Automatik !)

- Systemeinstellungen -> Sicherheit -> Hauptkennwort

- Systemeinstellungen -> Sharing -> Windows-Sharing

- starte Mail und Safari und prüfe sie auf volle Funktionstüchtigkeit beim Abruf von Seiten, für die du Kennwörter im Schlüsselbund hast.

- aktiviere einen Bildschirmschoner mit Kennwort und versuche ihn zu deaktivieren.

Wenn diese letzten Schritte alle geklappt haben, schick Winnie und seinen Spezi nach Belieben in den Orkus. Das wars.
 

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
Ich schließe mich dem Posting von MacApple an. Das sicherste ist und bleibt einen neuen Admin User anzulegen, die Daten vom $HOME des alten zu übernehmen, chown rekursiv drüber und den alten Admin User zu löschen.
Bei allen anderen Methode in der Netinfo rumzufummeln ist das "Verletzungsrisiko" enorm hoch. Außerdem reicht es beim manuellen Weg nicht, nur die Netinfo zu ändern. Auch der Apache weis von Deiner Existenz, CUPS, SSH...

Fazit: Die enorme Arbeit und das Risiko zahlen sich IMHO überhaupt nicht aus.

Außerdem: Wenn Du wirklich so brav bist und mit einem unpriviligierten User arbeitest und einen eigenen Admin User hast, warum willst Du dessen Kurznamen unbedingt ändern?

Gruß Pepi
 

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
pepi schrieb:
Ich schließe mich dem Posting von MacApple an. Das sicherste ist und bleibt einen neuen Admin User anzulegen, die Daten vom $HOME des alten zu übernehmen, chown rekursiv drüber und den alten Admin User zu löschen.
Und genau das ist falsch.
Denn der neue Nutzer hat eine neue UID und etliche Dateien aus seinem Preferences-Ordner sowie dem lokalen Cache des Systems werden ihre Funktion einstellen. (Weil dort die alte UID noch abgelegt ist).
Auch der Schlüsselbund wird bei bestimmten Kennworten anfangen, Zicken zu machen.
Deine Methode ist zwar einfach, aber bringt Fehler mit sich.

Bei allen anderen Methode in der Netinfo rumzufummeln ist das "Verletzungsrisiko" enorm hoch. Außerdem reicht es beim manuellen Weg nicht, nur die Netinfo zu ändern. Auch der Apache weis von Deiner Existenz, CUPS, SSH...
Du irrst dich. Die erfahren das *alle* von NetInfo und daher ist das genau der *einzig* richtige Platz, das zentral fürs gesamte System zu ändern.
 

pepi

Cellini
Registriert
03.09.05
Beiträge
8.740
@Rastafari,
irgendwie erscheint mir Dein Posting widersprüchlich. Bitte korrigiere mich, wenn meine Interpretation falsch ist.

Denn der neue Nutzer hat eine neue UID und etliche Dateien aus seinem Preferences-Ordner sowie dem lokalen Cache des Systems werden ihre Funktion einstellen. (Weil dort die alte UID noch abgelegt ist).
Ja, der neue Benutzer hat eine neue UID, das ist meines Erachtens nicht weiter gefährlich. Die Dateien aus seinem Preferences Ordner (~alteruser/Library/Preferences ) bekommen durch das erwähnte rekursive chown neuerusername als Eigentümer den neuen User, wieso diese Dadurch "ihre Funktion einstellen" sollten mag sich mir überhaupt nicht zu erschließen. Die Zugriffsrechte sind ident wie vorher, der Eigentümer ist der entsprechende User.

Dateien aus dem lokalen Chache (/Library/Caches) werden mit .uid abgeschlossen. Der neue user wird also garnicht versuchen Cache Dateien des alten Users zu verwenden.

snip aus meinem /Library/Caches Ordner:
-rw------- 1 pepi admin 1445888 Nov 8 23:50 com.apple.dock.iconcache.501
-rw------- 1 itunes admin 1118208 Sep 23 01:33 com.apple.dock.iconcache.502
-rw------- 1 gamer admin 1118208 Sep 11 17:59 com.apple.dock.iconcache.503
Auch hier sehe ich kein Problem, außer das ein paar ungenutzte Dateien auf der Platte verbleiben. die Natur eines Caches ist es, daß er wenn fehlend neu aufgebaut wird. Daher könnte man präventiv den Cache Ordner entleeren. Ich persönlich halte das durchaus für sinnvoll, aber fürs reine Funktionieren nicht zwingend notwendig.

Auch der Schlüsselbund wird bei bestimmten Kennworten anfangen, Zicken zu machen.
Bei welchen Kennworten passiert dies bitte, und warum? Kann ich überhaupt nicht nachvollziehen, es sei denn die Schlüsselbunddatei ist beschädigt. Dies kann man mittels "Schlüsselbund Erste Hilfe" auf jeden Fall überprüfen.
Wenn man beim neuen User das idente Kennwort wie beim alten zu ersetzenden User angibt ist es meiner Erfahrung nach nichteinmal notwendig sich näher mit dem Schlüsselbund zu befassen. Das Keychain Framework unterscheidet nur Passwörter für Schlüsselbund Dateien, es gibt dort keine Benutzernamen. Nachdem die Schlüsselbund Datei ( ~/Library/Keychains/login.keychain bzw. ~/Library/Keychains/shortname.keychain für Upgegradete Systeme) innerhalb von ~/ liegt wird sie ebenfalls durch das erwähnte chown dem korrekten User zugewiesen. Für ein upgegradetes System empfiehlt es sich selbstverständlich den Namen der Schlüsslbund Datei entsprechend auf login.keychain zu ändern.

Meine Methode ist bewußt einfach und ich habe diese auch schon mehrfach Problemlos angewandt. Die von Dir erwähnten Fehler kann ich bisher nicht nachvollziehen. Vielleicht gibst Du uns dazu bitte noch etwas mehr Information, da mich dieses Thema als Mac Sysadmin natürlich sehr interessiert. Ich finde es nicht schlecht dem System das Anlegen und Entfernen von Benutzern zu überlassen, da die SystemEinstellungen > Benutzer wohl ganz genau wissen, was sie wo überall eingetragen haben.

Die erfahren das *alle* von NetInfo und daher ist das genau der *einzig* richtige Platz, das zentral fürs gesamte System zu ändern.
Dies ist so leider nicht korrekt. Als konkretes Beispiel dazu: Apache

[pepi@bauxite-en1:~]$ ls -la /etc/httpd/users/
total 24
drwxr-xr-x 5 root wheel 170 Sep 11 14:51 .
drwxr-xr-x 10 root wheel 340 Jul 19 11:16 ..
-rw-r--r-- 1 root wheel 141 Sep 11 14:51 gamer.conf
-rw-r--r-- 1 root wheel 142 Aug 9 18:32 itunes.conf
-rw-r--r-- 1 root wheel 140 Jul 19 11:34 pepi.conf

Apache sieht in der Mac OS X Client Standardkonfiguration keine Authentifizierung vor, kümmert sich aber mit dem UserDir Modul um die ~/Sites Ordner der Benutzer.

snip aus der /etc/httpd/httpd.conf:
# UserDir: The name of the directory which is appended onto a user's home
# directory if a ~user request is received.
#
<IfModule mod_userdir.c>
UserDir Sites
</IfModule>
-------------------
Hier wird die Netinfo überhaupt nicht konsultiert. Dein neuer User könnte also ohne manuelles nachbessern der config files (sprich umbenennen derselben Userconfig) kein funktionierendes Sites Directory in seinem neuen Benutzer.

Soweit mir bekannt nutzen alle Authentifizierungsmechanismen unter Mac OS X Client eine Art von Wrapper für die Netinfo (via lookupd, netinfod) um auf deren Benutzerdaten zuzugreifen. Dies greift jedoch nur dann wenn es auch um authentifizierung geht.

Es gibt durchaus einige Fälle wo ein username in Flatfiles zur Konfiguration abgelegt wird. (Siehe Apache Beispiel). All diese Fälle werden durch bloßes Ändern in der Netinfo nicht berücksichtigt. Es muß nicht zwangsläufig gewfährlich für das System sein, aber durchaus zum Verlust von Funktionalität kommen. Außerdem gehst Du nicht auf Apache, Samba config, crontab etc. ein. Das sind alles Sachen die Du auch manuell machen müßtest um den User vollständig zu bearbeiten. Beim anlegen eines neuen Users kannst Du Dich definitiv drauf verlassen, daß dies erledigt wird. (Auch wenn man seine cron Jobs manuell übernehmen muß)

Gut fand ich übrignes Deine Warnung zum Editieren der Netinfo. Ich habe hier auch vor einigen Jahren vieles "auf die harte Tour" gelernt. Auch ein sehr guter Punkt war, daß man unbedingt FileVault abschalten sollte!
Gruß Pepi
 
  • Like
Reaktionen: mullzk

Rastafari

deaktivierter Benutzer
Registriert
10.03.05
Beiträge
18.150
pepi schrieb:
Ja, der neue Benutzer hat eine neue UID, das ist meines Erachtens nicht weiter gefährlich.
Aus Sicht des Security.framework handelt es sich um einen *anderen* Benutzer.
Du magst dir ausmalen können, was das für gewisse kennwortgeschützte Dienste bedeutet.

Die Dateien aus seinem Preferences Ordner (~alteruser/Library/Preferences ) bekommen durch das erwähnte rekursive chown neuerusername als Eigentümer den neuen User, wieso diese Dadurch "ihre Funktion einstellen" sollten mag sich mir überhaupt nicht zu erschließen. Die Zugriffsrechte sind ident wie vorher, der Eigentümer ist der entsprechende User.
Aber in vielen Dateien ist die UID in Textform oder auch im Dateinamen hart einkodiert. Das alles änderst du eben *nicht* mit.

Dateien aus dem lokalen Chache (/Library/Caches) werden mit .uid abgeschlossen. Der neue user wird also garnicht versuchen Cache Dateien des alten Users zu verwenden.
Die Nutzerrechte regeln zwar, wer auf eine Datei zugreifen *kann*, aber das Namenssuffix steuert, mit welcher Datei das überhaupt *versucht* wird.
Auf den ersten Blick mögen nur einige Dateileichen herumliegen... aber was passiert, sobald du einen neuen Benutzer anlegst, der diese verschlissene UID erneut zugeteilt bekommt?
Der steht dann vor unbenutzbaren Dateien und sein Account spinnt sich den Wolf...

Du findest das übrigens auch in /tmp, /var/tmp, /Library/Logs/......etcetera
Auch die mds-Einstellungen (a.k.a. 'Kindersicherung') sind betroffen.

Bei welchen Kennworten passiert dies bitte, und warum?
Windows Share (SAMBA) ab Version ???
Und andere. Frag mich jetzt aber bitte nichts präzises, müsste ich nachschlagen.

Kann ich überhaupt nicht nachvollziehen, es sei denn die Schlüsselbunddatei ist beschädigt. Dies kann man mittels "Schlüsselbund Erste Hilfe" auf jeden Fall überprüfen.
Würdest du es 'angemessen' finden, wenn jeder andere Benutzer *deine* Schlüsselbunddatei 'fixen' könnte??
Siehst du...

Wenn man beim neuen User das idente Kennwort wie beim alten zu ersetzenden User angibt ist es meiner Erfahrung nach nichteinmal notwendig sich näher mit dem Schlüsselbund zu befassen. Das Keychain Framework unterscheidet nur Passwörter für Schlüsselbund Dateien, es gibt dort keine Benutzernamen.
Kennwörter werden in Form von Hashwerten verarbeitet und geprüft.
Zwei verschiedene Benutzer haben nie gleiche Hashwerte, auch bei gleichem Kennwort nicht.

Nachdem die Schlüsselbund Datei ( ~/Library/Keychains/login.keychain bzw. ~/Library/Keychains/shortname.keychain für Upgegradete Systeme) innerhalb von ~/ liegt wird sie ebenfalls durch das erwähnte chown dem korrekten User zugewiesen.
Für eine digitale Signatur sind Eigentümerrechte ziemlich irrelevant. Da lässt sich nicht eine jede von jedem Benutzer verwenden - auch nicht, wenn du sie ihn beliebig lesen und schreiben lässt.

Ich finde es nicht schlecht dem System das Anlegen und Entfernen von Benutzern zu überlassen, da die SystemEinstellungen > Benutzer wohl ganz genau wissen, was sie wo überall eingetragen haben.
Da kann ich dir nur beipflichten. Allerdings weiss ich, dass Benutzer denen man keine Informationen gibt, hartnäckig auf eigene Faust herumprobieren.
Das ist vermeidbar.

Apache sieht in der Mac OS X Client Standardkonfiguration keine Authentifizierung vor, kümmert sich aber mit dem UserDir Modul um die ~/Sites Ordner der Benutzer. ...
Hier wird die Netinfo überhaupt nicht konsultiert. Dein neuer User könnte also ohne manuelles nachbessern der config files (sprich umbenennen derselben Userconfig) kein funktionierendes Sites Directory in seinem neuen Benutzer.
Du brauchst das Websharing nur neu zu aktivieren und der "Fehler" wird beseitigt.
Solange du nicht selbst Hand angelegt hast, wirst du nichts bemerken.

Soweit mir bekannt nutzen alle Authentifizierungsmechanismen unter Mac OS X Client eine Art von Wrapper für die Netinfo (via lookupd, netinfod) um auf deren Benutzerdaten zuzugreifen. Dies greift jedoch nur dann wenn es auch um authentifizierung geht.
Das greift immer. Die 'klassischen' Unix-Config-Dateien ('flat files') werden von NetInfo automatisch generiert, wenns sein muss. Das funktioniert mit den meisten Diensten.
Ein Beispiel, wie das geht liefert dir 'nidump'.

Beim anlegen eines neuen Users kannst Du Dich definitiv drauf verlassen, daß dies erledigt wird.
Das ist richtig. Allerdings musst du das dann auch konsequent machen und den Nutzer mit einem neuen, leeren Library-Ordner ohne irgendwelche Dateileichen ins Leben starten lassen. Sonst klemmt was.
 

commander

Baldwins roter Pepping
Unvergessen
Registriert
25.02.04
Beiträge
3.206
Und der arme Alejandro lässt es mal lieber gleich ganz bleiben: der Aufwand rentiert sich nicht. ;)

Gruß,

.commander
 

Alejandro

Transparent von Croncels
Registriert
08.10.05
Beiträge
306
@commander:

Ja, da hast du Recht. Ich werde es wohl lassen. So wichtig ist es dann doch nicht...
Trotzdem Danke für eure ausführlichen Antworten.