macOS: Prozess „auccountsd“ beansprucht 100% Rechenleistung

In letzter Zeit nutze ich seltener mein heißgeliebtes MacBook (MacBook Pro, Retina 13″, 3 GHz CPU, 16GB RAM, 250 GB SSD, Mid 2014). Der Grund ist zunehmender Platzmangel auf der internen SSD und ich muss ständig irgendwelche Dinge löschen oder umsortieren. Dazu fehlt mir oft Lust und Zeit im Moment.

Heute gab es jedoch mal wieder einen Grund, das MacBook aufzuklappen und sofort empfing es mich mit lustigem Rauschen nach dem Anmelden.

OK – Neustart.
Kommt ja schon mal vor bei Äpfeln, die seit Monaten im Schlaf liegen, ohne ein- & ausgeschaltet zu werden.

Und wieder schönes Rauschen nach dem Anmelden.
OK  – schauen wir mal unter die Haube, was da die CPU so beansprucht, dass der Lüfter sich genötigt fühlt, für Kühlung sorgen zu müssen.

Ein gutes Hilfsmittel, um Amok laufende Prozesse oder Ressourcenfresser auszumachen, ist die Aktivitätsanzeige vom MAC OS.

Schnell den Spaltenkopf % CPU mit der prozentualen Anzeige des Ressourcenverbrauch der jeweiligen APP oder des jeweiligen (System-)Prozesses anklicken, um nach dem größten CPU-Last Verbraucher zu sortieren.

Bei einem ruhenden System, ohne laufende APPs und ohne Hintergrundprozesse, wie z.B. Cloudsynchronisations-, Antivirus- oder Updatevorgänge, sollte dort keine Prozentzahl deutlich über 20% auftauchen.

157% CPU-Zeit … da muss man sich nicht lange fragen, ob etwas schief läuft.

 

Ein Blick in die Interna dieses Prozesses (Doppelklick auf den Prozesseintrag) zeigt recht schnell, womit er sich beschäftigt:

Nach ein bisschen Scrollen im Tab Geöffnete Dateien und Ports zu den Task-Interna von accountsd finde ich den Eintrag

[…] /System/Library/Accounts/Authentication/icloudIDAuthentication […]

Der Prozess accountsd kümmert sich also augenscheinlich u.a. um die Synchronisation der eingerichteten Mailaccounts. Da Mail bei mir in dem Moment gar nicht lief, kann es sich also nur um ein Problem bei den zugehörigen Hintergrundprozessen handeln. Also z.B. das Abfragen auf neue Emails.

Da alle Accounts bei mir via IMAP eingerichtet sind, war es kein Problem, sie mal testweise zu deaktivieren.
Als das jedoch nur ein Absenkung auf ca. 100% +/- 10 % brachte, habe ich sie nach und nach gelöscht und wieder hinzugefügt (sofern man seine Accountdaten ordentlich im Griff hat – kein Problem).

Das Problem war ein Exchange-Account, der serverseitig mit einem privaten Zertifikat arbeitet. Wird zwar von Apple Mail bei der Einrichtung akzeptiert, sorgt aber offenbar irgendwann für Sand im Getriebe. War der Account nicht vorhanden, gab es keine Probleme und das System blieb flüsterleise.

Also habe ich den Account weggelassen und werde ihn zukünftig über OutlookWebAccess abfragen. Kein sehr befriedigende Lösung haben aber zumindest schnell — und leise 🙂 !!

 

Wenn dieser Post jemandem geholfen hat, würde ich mich über ein kurzes Dankeschön als Kommentar und ggfls. die Verlinkung in anderen Blogs oder Foren freuen !!

 

Advertisements

Probleme mit Umlauten im LDAP-Attribut CN

Probleme mit Umlauten im LDAP-Attribut CN

Endlich …

Nach ziemlich langer Abstinenz im Stromzoo habe ich mich gestern dazu entschieden, weder ein paar Zeilen zu schreiben, da ich eine entsprechende Info im Netz nur sehr schwer finden konnte.
Der Grund hierfür dürfte mal wieder sein, das Profis gar nicht auf so ein Problem kommen würden, auf das Mausschubser wie ich allzu leicht hereinfallen …

 

Dummes LDAP-Problem

Ich will gar nicht so weit ausholen und vor Allem will ich nicht mein Problem an sich rechtfertigen – denn Schuld (aus dilettanter Unwissenheit) am Problem bin ich selbst … und Microsoft ….

Wie immer gibt es bei Microsoft 365 Wege, etwas zu erledigen im System. Via Benutzeroberfläche für dilettantische Mausschubser (ich) und oder per Scripting für Puristen, Perfektionisten, Nerds und Masochisten (nicht ich … na ok, manchmal).

In diesem Fall handelt man sich das Problem ein, wenn man bei der Anlage eines User-Accounts via Management-SnapIn als Vollständiger Name einen evtl. vorhandenen Umlaut einträgt, wie beim Toni Täster im Beispiel:

1

Wie in Microsoftprodukten oft üblich, nimmt das SnapIn die Umlaute an, ohne sich zu beschweren, obwohl sie nicht den RFC-Richtlinien (RFC4514) entsprechen.

Dieser Distinguished Name findet sich dann auch brav als CN-Attribut in der Attributliste des Users:

4

Meist wird einem niemals ein wirklicher Fehler begegnen, zudem freut es den Anwender sicher, seinen „richtigen“ Namen in Verzeichnislisten vorzufinden.
Wie immer im Leben, begegnet man irgendwann einmal einer Situation, in der sich die alten Fehler rächen.

Setzt man allerdings eine Software ein, die auf das LDAP-Attribut CN referenziert, in dem nämlich dieser Vollständige Name (Distinguished Name) wie oben gezeigt abgelegt wird, wird es ärgerlich.

Intern interpretiert das LDAP den Umlaut offenbar als einfachen Vokal. Aus einem ä wird ein a und aus einem ö ein o etc. – eben nicht ae für ä oder oe für ö !!!

Das muss man wissen, ansonsten wird man z.B. bei Logins in Software die auf das LDAP-Attribut CN als User-Loginname referenziert schlicht wahnsinnig.

 

Lösung 1

Man benennt das CN-Attribut um.
Kann man im CN-Attribut mit Doppelklick selbst machen :

5

Nach dem Klick auf OK, scheint das auch geklappt zu haben. Will man danach die Änderungen in den User-Eigenschaften mit Übernehmen akzeptieren, erscheint eine Fehlermeldung:

6

Super Microsoft !!
Aber es geht natürlich an anderer Stelle. Einfach in der Liste der Userprofile den User markieren und aus dem Kontextmenü Umbenennen wählen oder F2 drücken, oder langsamen Doppelklick auf den Namen machen oder … oder  …. (s.o.)

Danach ist das LDAP-Attribut CN des Users entsprechend geändert :

9

Jetzt klappt auch das Login bei Software, die auf das LDAP-Attribut CN referenziert.

 

„Lösung“ 2

… ist eigentlich gar keine Lösung, sondern berücksichtig die Art und Weise, wie das LDAP mit Umlauten umgeht.

Ist als CN ein Wert mit Umlaut eingetragen, wird dieser bei Software, die für den User-Login auf dessen LDAP-Attribut CN als Usernamen referenziert, einfach ignoriert und als einfacher Vokal eingetragen.

Beispiel:

LDAP-Atttribut CN = Toni Täster

Userloginname = Toni Taster

 

WordPress-Plugin LDAP-Login for WordPress

Bei der Konfiguration und Nutzung des Plugins von miniorange ist mir das Problem begegnet. Das Plugin LDAP-Login for WordPress sorgt dafür, dass LDAP-User eines Netzwerkes sich mit ihrem Usernamen & Passwort aus dem LDAP anmelden können.

Das Plugin referenziert dabei auf das LDAP-Attribut CN als Usernamen, während normalerweise in Windows auf das LDAP-Attribut sAMAccountName oder userPrincipalName zum Login referenziert wird.

Das ist zunächst einmal das Erste, was man verstehen muss. Das Login mit dem sAMAccountName steht erst in der Premium-Version zur Verfügung, die z.Zt. schlappe 349$ kostet …

Zum einen ist also genau die Schreibweise zu beachten, wie sie im Attribut CN abgelegt ist, zum Anderen ist auf die Besonderheit im Umgang mit Umlauten zu achten, wie vorher beschrieben.

Will oder kann man also im LDAP nichts ändern und nicht die Dollars für die Premium-Version des Plugins investieren, so ist die oben beschrieben Lösung 2 der einfachste Weg !!
Der in der Oberfläche angezeigte Name kann dann nachträglich in der Benutzerprofilverwaltung von WordPress umgeändert werden.

 

Hier gilt also wie immer … kaum macht man’s richtig … schon funktioniert’s ….

 

Quellen:

lesbare Infos zum Thema CN-Attribut

Hinweis zur „Lösung“ 2

LDAP-Login for WordPress von miniorange und auf WordPress.org

 

gehelft

Wenn dieser Post jemandem geholfen hat, würde ich mich über ein kurzes Dankeschön als Kommentar und ggfls. die Verlinkung in anderen Blogs oder Foren freuen !!