Archiv für den Monat: Oktober 2013

VCenter Probleme mit SSO (Authorize Execption und Timeout)

Wenn die Verbindung zum Active Directory  mit „Authorize Exception“ und/oder einem Timeout „Zeitüberschreitung / The server took too long to respond“ nicht mehr funktioniert, sollte man die AD Verbindung mit dem „rsautil“ neu anlegen. Benötigt wird der „admin“ den man bei der Installation von SSO angelegt hat:

Zum Ordner wechseln der das Tool beinhaltet:
cd c:\Program Files\VMware\Infrastructure\SSOServer\utils

Anzeigen der aktuellen Verbindungen:
rsautil manage-identity-sources –a list

Löschen der alten defekten Verbindung:
rsautil manage-identity-sources –a delete
Man muß die ID der AD Verbindung angeben – Markieren und Einfügen erleichtert die Arbeit enorm 🙂

Verbindung neu anlegen:
rsautil manage-identity-sources –a create und den Dialog durchgehen. Bei der LDAP Connection den Port 3268 (z.B. ldap://dc.domain.tld:3268) oder 3269 (mit SSL) setzen, denn sonst wird der Port 389 genutzt.

rsautil

Port 3268. This port is used for queries specifically targeted for the global catalog. LDAP requests sent to port 3268 can be used to search for objects in the entire forest. However, only the attributes marked for replication to the global catalog can be returned. For example, a user’s department could not be returned using port 3268 since this attribute is not replicated to the global catalog.

Port 389. This port is used for requesting information from the local domain controller. LDAP requests sent to port 389 can be used to search for objects only within the global catalog’s home domain. However, the requesting application can obtain all of the attributes for those objects. For example, a request to port 389 could be used to obtain a user’s department.

Nun mit dem lokalen Administrator des VCenter Servers anmelden und evtl. die Berechtigungen neu setzen.

Desweiteren sollten die AD Einstellungen im VCenter entschärft werden:

vcenter-ad

Quagga: Static Route „Metric Bug“ in Ubuntu LTS

In der Routing Suite „Quagga“ unter Ubuntu 12.04.3 LTS gibt es einen Bug: wenn man eine Metric zu einer statischen Route angibt, wird diese immer auf „0“ gesetzt. Ein Test mit der recht aktuellen Version 0.99.22.1 in Ubuntu 13.10 verlief jedoch erfolgreich:
static-1
static-2
Für die meisten Anwendungsfälle ist die Metric bei statischen Routen auch nicht so wichtig, aber ich wollte eine Route vom OSPF ausnehmen und als Failover eine schlechtere statische Route auf ein Alternativ-Gateway setzen.

Sophos UTM 9 – OSPF über einen VPN-Tunnel nutzen

Bei der Sophos UTM ist es leider nicht möglich mittels Webinterface interne Netzwerke per OSPF über einen IPsec oder SSL-VPN Tunnel zu verbreiten. Man kann kein OSPF Interface anlegen welches vom VPN genutzt wird (z.B. tun0). Sophos/Astaro nutzt die Routing Suite „Quagga“, jedoch ist per Webinterface nur ein Bruchteil der Funktionen nutzbar. Jede Anpassung in der Shell führt zum Supportverlust. Ich habe per Webinterface nur einen Weg gefunden: Ein RED (Remote Ethernet Device) zu nutzen. Dieses ist nicht nur mit der Sophos eigenen Hardware Appliance RED möglich, sondern kann auch von UTM zu UTM realisiert werden. Nachdem der Tunnel aufgebaut ist, kann man auf beiden UTMs ein Interface anlegen und in eine Area beim OSPF aufnehmen. Hier einige Screenshots:

Auf der UTM die den „Server“ anbieten soll:
red-type
red-server
Auf der Client UTM:
red-client
Nun kann man das Device anlegen:
interface-red
interface-red2
Anschliessend das Device im OSPF einbinden:
ospf-interface
Und der entsprechenden Area hinzufügen:
ospf-area