Zentral verwaltete WLAN-Infrastruktur über mehrere Standorte

Du solltest dich bei außer beim oben genannten auch Meru, Cisco, Aruba oder Motorola umsehen. Alle diese Hersteller supporten umfassend alles was du richtigerweise auf deiner Anforderungsliste hast. Fokus Meru, Aruba, Cisco so in der Reihenfolge.
Das ist ein sehr gängies Anforderungsprofil was du hast. Kein Wunder, denn 98% aller mittleren und größeren Unternehmen sehen so aus.
Über unterschiedliche Profile in den WLAN Controllern kann man diese dann sehr granular steuern. Alle oben genannten Hersteller supporten das und unterscheiden sich nicht groß sondern eher in Details. Erfüllen tun sie allesamt deine Anforderungen.
Etwas herausstechen tut hier Meru mit ihrem Single Channel, Virtual Cell Verfahren, was die leidige WLAN Frequenzplanung erheblich vereinfacht. Durch ein Zeitslot Verfahren was die anwenden erhält man quasi als Nebenprodukt eine relativ gesicherte Bandbreite.
Es ist klar das du ein Controller basiertes WLAN aufbauen musst. Alles andere wäre wieder eine Bastellösung.

Das kann nicht ersthaft ein Problem sein. Wir setzen nach einigem Vendorhopping momentan nur noch 2 Systeme ein: Im kostensensiblen Bereich ZyXEL und bei einigen "Leuchtturmprojekten" MeruNetworks. Die Controller von Meru unterstützen je nach Modell zwischen 50 und 5000 Accesspoints. Darüber hinaus kann man seine Controllerfarm auch über die Managementsoftware "E(z)RF" zentral verwalten und darüber (fast) wie einen einzigen Controller behandeln.
Selbst bei Billigheimer ZyXEL unterstützt der kleinste Controller (NXC2500) schon bis zu 64 Accesspoints und der größte (NXC5500) bis zu 512 APs. Auch hier gibt es optional eine Managementsoftware, welche (unter anderem) die Controller übergreifend verwalten kann.
Ich kann mir nicht vorstellen, dass es bei anderen Herstellern diesbezüglich viel schlechter aussieht, denn die stehen ja in direktem Wettbewerb.
Beschränkungen auf 24 oder 25 Accesspoints kenne ich nur, wenn ein Accesspoint als Controller umfunktioniert wird. Das sind aber ohnehin nur Systeme für Kleinstumgebungen und die Appetitmacher für den Verkauf der "richtigen" Controller. Dementsprechend ist das Featureset auch meist etwas eingeschränkt.



Das ist früher mal so gewesen. Seit der Einführung von 802.11n gibt es keinen namhaften Hersteller mehr, der den Traffic nicht auch lokal auskoppeln könnte, denn bei den nunmehr höheren Datenraten im WLAN würde der Controller schnell zum Flaschenhals.
Richtig ist allerdings, dass für bestimmte Funktionalitäten oftmals weiterhin ein Tunneling zum Controller erforderlich ist. Prominentestes Beispiel (und hier offenkundig das Problem) ist die Bereitstellung eines Captive Portals. Sofern hierfür die integrierte Funktionalität genutzt werden soll, übernimmt diese Aufgabe in der Regel der zentrale Controller. Damit dies funktioniert, müssen 2 Dinge gewährleistet sein:
1) Der Traffic muss durch den Controller hindurch und es muss sichergestellt sein, dass dieser nicht umgangen werden kann.
2) Der Controller muss die MAC-Adressen der Clients "sehen", da hierauf die Freischaltung beruht. Wäre die Verbindung geroutet, würde die MAC des letzten Hops freigeschaltet und damit sämtliche dahinter befindlichen Clients.
Deshalb wird bei Einsatz eines zentralen Captive Portals das Gast-WLAN in der Regel per GRE-Tunnel vom Accesspoint zum Controller geführt.

Wenn dies in Deiner Umgebung aufgrund fehlender Bandbreite nicht praktikabel ist, dann gibt es folgende Alternativen:
a) Du koppelst den Traffic lokal aus und lässt die CP-Bereitstellung durch eine lokale Komponente übernehmen (z.B. durch die lokale Firewall oder durch jeweils ein spezielles Hotspotgateway).
b) Du suchst Dir ein System, bei dem das CP nicht durch den Controller, sondern durch jeden einzelnen Accesspoint oder durch einen AP des lokalen AP-Verbunds bereitgestellt wird. Es gibt Hersteller, die sich einen komplett controllerlosen Ansatz auf die Fahnen geschrieben haben und daher sämtliche Intelligenz in die Accesspoints legen - einschließlich Firewallpolicies und Layer7-Inspection! Ich würde erwarten, dass hier auch das CP dezentral organisiert ist. Ein solcher Hersteller wäre z.B. AeroHive.


Gruß
sk

Wenn es wirklich nur um die privaten Mobilgeräte der Mitarbeiter (und bestenfalls gegentlich um "echte" Gäste) geht, dann lass den Unsinn mit der CaptivePortal-Authentifizierung. Sichere das GastWLAN per WPA2-Enterprise und authentifiziere die User gegen Ihre Konten im AD.

Gruß
sk

Servus,

sag einmal, wie das WLAN genutzt werden soll und wie viele User pro Standort ins WLAN sollen.

Technisch ist fast alles machbar, aber die von sk angesprochene Lösung willst du dir für wenige User vermutlich nicht leisten, wenns nur um ein bisschen komfortables arbeiten mit Mobilgeräten geht.

Grüße, Stefan

Hat auch niemand vergeschlagen.



Und was von dem Vorgetragenen spricht nun konkret gegen den (ggf. partiellen) Einsatz von WPA-Enterprise/802.1x und dagegen, ggf. bereits im AD vorhandene Konten für die Authentifizierung mit heranzuziehen? Ich kann da bei bestem Willen keine besonderen Herausforderungen entdecken.
Die Authentifizierungsmethode (802.1x vs. PSK vs. CP) ist eine Sache. Die Frage, wo und wie welche Anmeldeinformationen gespeichert sind und wie diese verwaltet werden, ist eine andere. Und die Frage, mit welchen Anmeldeinformationen man in welches WLAN kommt bzw. welche Rechte man hat, nachdem man sich authentifiziert hat, ist wiederum eine dritte Sache, die es zu betrachten gilt. Alle 3 Aspekte lassen sich den individuellen Anforderungen entsprechend zu einer geeigneten Lösung kombinieren.
Meine obige Einschränkung ("bestenfalls gegentlich um echte Gäste") bezog sich vorallem auf ein Gedankenspiel meinerseits, dass man die Anmeldeinformationen der Gäste ggf. auch individuell oder generalisiert/auf Vorrat im AD speichern könne, um das technische Konstrukt und den Kostenrahmen klein zu halten. Je nach organisatorischen und funktionellen Anforderungen macht es natürlich Sinn, (zumindest auch) spezialisierte Authentifizierungsserver einzusetzen. Zu denken wäre hier bespielsweise an Meru Connect (ehemals Identity Manager), Aruba Clearpass u.ä.


Gruß
sk

Moin,
Bei uns kann der Mitarbeiter sein Geräte über ein Portal selbst de/registieren. Somit entfällt bei der Supportabteilung einiges an Aufwand. Via E-Mail/SMS erhält er seine Zugangsdaten.

Wenn das nur auf geschäftliche Geräte zutrifft würde ich auf Zertifikate (Computer) setzen. Bei deiner Variante könnte der MA sein privates Tablet nehmen und dort bei Nachfrage seine AD-Nutzerdaten eingeben.


Gruß,
Dani

Das ist mal wieder ein typisches Denkverbot ohne technischen Grund. Inwiefern sollte es denn problematisch sein, wenn über die Sicherheitsrichtlinien des ADs und des NPS gewährleistet ist, dass diese Konten für nichts anderes verwendbar sind, als zur Anmeldung am Gäste-WLAN (per Captive Portal oder 802.1x)? Nur weil im AD ein Konto existiert, muss man sich damit noch lange nicht an irgend einem Rechner im internen Netz anmelden können! Man könnte das AD durchaus ohne irgendwelche Sicherheitsrisiken zur Speicherung der Anmeldeinformationen nutzen. Vorallem kann man damit auch schön die Verwaltung dieser Konten an (berechtigte) Nichtadmins delegieren. Alles mit Boardmitteln und für lau!
Ich sage ja nicht, dass dies im vorliegenden Fall die beste Lösung ist, aber zumindest sollte man mal die Scheuklappen ablegen (dürfen) und prüfen, welche Möglichkeiten sich einem aufgrund der vorhandenen Infrastruktur bereits bieten.



Umständlich oder? Warum nicht ein zentrales System, welches es der IT-Abteilung ermöglicht, die Anlage und Verwaltung der Zugangsdaten granular an berechtigte Personenkreise zu delegieren?
Nennen wir diese Personenkreise einfachen "Sponsoren". Wie wäre es, wenn Sponsorgruppe A per Webinterface Benutzerkennungen generieren könnte, die nur für WLAN A nutzbar sind und maximal 24h Gültigkeit haben? Gleichzeitig könnte es eine Sponsorengruppe B geben, die Zugänge nur für WLAN B und mit einer deutlich längeren Gültigkeit generieren darf, während die Sponsorengruppe C selbiges für beide WLANs darf. Eine weitere Sponsorengruppe D darf vielleicht nur Voucher auf Vorrat ausdrucken und gegen Unterschrift rausgeben. Diese Voucher funktionieren nur am WLAN D oder wenn gewünscht auch an anderen Standorten. Interne Benutzer könnten sich nach Aufnahme in eine spezielle AD-Gruppe mit ihren privaten Geräten mittels der Zugangsdaten aus dem AD an den Gäste-WLANs anmelden. Oder wie wäre es, wenn die User Ihre eigenen Geräte auf einem Selfserviceportal registrieren könnten, woraufhin die Sponsorengruppe E eine e-Mail erhält, um diesen Antrag zu prüfen und "per Klick" zu genehmigen/freizuschalten?
Und die IT-Abteilung hat - von der Verwaltung der Sponsoren abgesehen - im Tagesgeschäft mit der Userverwaltung nichts zu tun, sieht aber dank zentralem Logging trotzdem jederzeit, wer wann ins WLAN eingebucht war, welcher Sponsor diese User wann angelegt hat usw.
Wäre toll? Gibt es alles zu kaufen! Zwei Produkte habe ich oben genannt. Freilich ist die Einrichtung dessen nicht Plug-and-Play, sondern bedarf insbesondere bei der Integration der Systeme anderer Hersteller einiges an Know-How und intensiver Beschäftigung mit dem Thema.



Nein.


Gruß
sk

@..sk..
Dann hast du sicherlich für jedes Konto eine CAL gemietet/gekauft...

Gruß,
Dani

@@Dani: Der Hinweis auf eine ordnungsmäße Lizensierung ist natürlich richtig und wichtig, aber ich wollte mich eigentlich auf die Technik beschränken.
Das Thema CAL ist ohnehin ein weites Feld mit einigem Interpretationsspielraum. Wenn nach Devices lizensiert wird, kann man z.B. bei Verwendung von 802.1x mit Radius durchaus der Auffassung sein, dass man bestenfalls eine CAL pro Authenticator oder Radius-Proxy benötigt. Aber das gehört nicht hier her. Das bespricht man mit seinem Lizenzberater und seinem Rechtsbeistand.

Servus,

für das Gast-WLAN würde sich z.B. eine Lösung mit freeradius und MySQL anbieten, MySQL könnte in der Zentrale laufen, User lassen sich bequem per Webinterface verwalten.
Da lässt sich auch leicht irgendein Workflow für ein Zugangszettelchen basteln.

Damit hättest du fürs Personal die schon vorhandenen Lizenzen (WPA2-Enterprise gegen Windows-Server), Gäste verwaltest du (oder das Sekretariat oder wer auch immer) die Zugänge per Webinterface ohne zusätzliche Lizenzkosten.

Grüße, Stefan

Das wäre Unsinn wenn der TO sich für ein Controller basierendes WLAN eines renommierten Herstellers entscheidet, denn diese Hersteller haben allesamt ohne Ausnahme eine fertige Gäste WLAN Lösung inklusive Ticket System in ihre Controller integriert.
Eine zusätzliche Lösung ist damit überflüssig.

Für einfache WLANs lohnt (und macht mehr Sinn) statt aufwendiger Datenbank die bei Gästen eh überflüssig ist, immer Einmal Passwörter mit einem automatischen Voucher System zu verwenden.
Das sendet diese per SMS an Gäste oder gibt sie einfachst per Web GUI aus.
Wie sowas vollkommen unproblematisch mit ein paar Mausklicks zu erstellen ist erklären die Forums bekannten Tutorials hier:
WLAN oder LAN Gastnetz einrichten mit einem Captive Portal (Hotspot Funktion)
Für die Voucher Verwaltung:
Voucher für pfSense online verwalten und optional Voucher per SMS verschicken
und auch hier:
Netzwerk Management Server mit Raspberry Pi
"Workflow mit Zettlchen basteln" entfällt damit dann vollends !

Letztes Jahr selbst evaluiert, implementiert und seither in Betrieb (Meru Connect). Selfregistration and Approval war dabei aber von vornherein unerwünscht, so dass ich mich damit nicht näher beschäftigt habe. Wir nutzen es nur zur abgestuften Delegation der Zugangsverwaltung.

Gruß
sk