Top-Themen

AppleEntwicklungHardwareInternetLinuxMicrosoftMultimediaNetzwerkeOff TopicSicherheitSonstige SystemeVirtualisierungWeiterbildungZusammenarbeit

Aktuelle Themen

Administrator.de FeedbackApache ServerAppleAssemblerAudioAusbildungAuslandBackupBasicBatch & ShellBenchmarksBibliotheken & ToolkitsBlogsCloud-DiensteClusterCMSCPU, RAM, MainboardsCSSC und C++DatenbankenDatenschutzDebianDigitiales FernsehenDNSDrucker und ScannerDSL, VDSLE-BooksE-BusinessE-MailEntwicklungErkennung und -AbwehrExchange ServerFestplatten, SSD, RaidFirewallFlatratesGoogle AndroidGrafikGrafikkarten & MonitoreGroupwareHardwareHosting & HousingHTMLHumor (lol)Hyper-VIconsIDE & EditorenInformationsdiensteInstallationInstant MessagingInternetInternet DomäneniOSISDN & AnaloganschlüsseiTunesJavaJavaScriptKiXtartKVMLAN, WAN, WirelessLinuxLinux DesktopLinux NetzwerkLinux ToolsLinux UserverwaltungLizenzierungMac OS XMicrosoftMicrosoft OfficeMikroTik RouterOSMonitoringMultimediaMultimedia & ZubehörNetzwerkeNetzwerkgrundlagenNetzwerkmanagementNetzwerkprotokolleNotebook & ZubehörNovell NetwareOff TopicOpenOffice, LibreOfficeOutlook & MailPapierkorbPascal und DelphiPeripheriegerätePerlPHPPythonRechtliche FragenRedHat, CentOS, FedoraRouter & RoutingSambaSAN, NAS, DASSchriftartenSchulung & TrainingSEOServerServer-HardwareSicherheitSicherheits-ToolsSicherheitsgrundlagenSolarisSonstige SystemeSoziale NetzwerkeSpeicherkartenStudentenjobs & PraktikumSuche ProjektpartnerSuseSwitche und HubsTipps & TricksTK-Netze & GeräteUbuntuUMTS, EDGE & GPRSUtilitiesVB for ApplicationsVerschlüsselung & ZertifikateVideo & StreamingViren und TrojanerVirtualisierungVisual StudioVmwareVoice over IPWebbrowserWebentwicklungWeiterbildungWindows 7Windows 8Windows 10Windows InstallationWindows MobileWindows NetzwerkWindows ServerWindows SystemdateienWindows ToolsWindows UpdateWindows UserverwaltungWindows VistaWindows XPXenserverXMLZusammenarbeit
GELÖST

Zentral verwaltete WLAN-Infrastruktur über mehrere Standorte

Frage Netzwerke LAN, WAN, Wireless

Mitglied: jsysde

jsysde (Level 2) - Jetzt verbinden

17.01.2015 um 09:56 Uhr, 2904 Aufrufe, 20 Kommentare

Moin zusammen.

Wir betreiben weltweit mehrere Standorte, die alle per Site2Site-VPN (Cisco ASA 55x, überall) sternförmig mit der Zentrale verbunden sind; jeder Standort hat (mindestens) einen DC (2008R2 oder höher); je nach Anforderung noch weitere Server in den Locations, soweit alles gut und läuft.

Aktuell sind beim Thema WLAN nur Insellösungem Start, teils einfache APs, die direkt am DMZ-Interface der ASA hängen und per PSK den Gästen direkten Internetzugriff erlauben, teils kommen auf DD-WRT geflashte Linksys-APs in Verbindung mit einer m0n0wall als Captive-Portal zum Einsatz usw. - ein ziemliches Minenfeld in punkto zentrale Konfig/Verwaltung, von Troubleshooting & Co. will ich gar nicht erst anfangen....

Die Aufgabe lautet nun:
  • WLAN-Umgebung an jedem Standort realisieren, zentral verwaltbar vom Hauptstandort aus
  • WLAN-APs müssen sowohl im 2,4GHz als auch im 5GHz-Band erreichbar sein (802.11ac gefordert)
  • An jedem Standort müssen die APs Roaming beherrschen und die Clients nathlos untereinander weitergeben können
  • Multi-SSID an jedem Standort:
    • jeweils eine SSID pro Frequenzband für Gäste
      • Captive Portal mit jeweils lokalem Internet-Breakout vor Ort
      • kein Zugriff auf interne Resourcen (Abschottung per VLAN)
    • jeweils eine SSID pro Frequenzband für interne User
      • RADIUS-Authentifizierung
      • lokaler Internet-Breakout ohne Captive Portal vor Ort
      • Zugriff auf interne Resourcen muss gewährleistet sein

    Mein Problem, nach langer Recherche im Netz und diversen Telefonaten/Support-Kontakten mit unterschiedlichen Herstellern ist die zentrale Verwaltbarkeit in Verbindung mit den lokalen Internet-Breakouts vor Ort sowie die max. Anzahl der vom Controller unterstützten APs.

    Wir benötigen >30 APs (eher mehr, Anzahl Standorte steigt) um alle Standorte entsprechend "auszuleuchten", die meisten Controller machen bei 24 respektive 25 APs Schluss. Ausserdem kann keiner der bisher bekannten Controller den lokalen Internet-Breakout realisieren, vielmehr werden Internetzugriffe von allen APs über den Internet-Breakout, an dem auch der Controller hängt, geroutet.

    Meine Frage an euch:
    Hat jemand ein ähnliches Szenario am Laufen und kann eine Empfehlung aussprechen, welcher Hersteller für so etwas passende Hard-/Software liefern und im Zweifel auch supporten kann?

    Ich kann gerne mit mehreren Controllern leben, auch mit je einem "Child-Controller" pro Standort, sofern diese in der Lage sind, ihre Konfiguration zentral vom "Master-Controller" am zentralen Standort zu empfangen und eben die Clients über den jeweils lokalen Internetanschluss ins Netz zu schubsen.

    Bin auf Ideen und Vorschläge gespannt.

    Cheers,
    jsysde
Mitglied: 114757
17.01.2015, aktualisiert um 10:49 Uhr
Moin jsysde,

http://www.ubnt.com/unifi/unifi-ap/

Bietet alles was du forderst.
  • Unlimited Scaleability (Anzahl der Accesspoints nicht begrenzt)
  • Management Zentral oder via Cloud-Access
  • Multi-SSID mit VLANs pro Band
  • Radius / Guest Hotspot Portal / Voucher / Payment etc.
  • Gateway lässt sich ja pro VLAN definieren / aber auch pro AP
  • Wireless Uplinks (APs lassen sich drahtlos verbinden wenn keine Kabelverbindung möglich)
  • etc. pp Unify Controller Documentation

Kann ich nur Gutes von Berichten.

Gruß jodel32
Bitte warten ..
Mitglied: aqui
17.01.2015 um 11:41 Uhr
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.
Bitte warten ..
Mitglied: sk
17.01.2015, aktualisiert um 13:51 Uhr
Zitat von jsysde:
Mein Problem ... ist ... die max. Anzahl der vom Controller unterstützten APs. Wir
benötigen >30 APs (eher mehr, Anzahl Standorte steigt) um alle Standorte entsprechend
"auszuleuchten", die meisten Controller machen bei 24 respektive 25 APs Schluss.

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.


Zitat von jsysde:
Mein Problem ... ist die zentrale Verwaltbarkeit in Verbindung mit den
lokalen Internet-Breakouts ... keiner der bisher bekannten Controller [kann] den lokalen
Internet-Breakout realisieren, vielmehr werden Internetzugriffe von allen APs über den
Internet-Breakout, an dem auch der Controller hängt, geroutet.

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
Bitte warten ..
Mitglied: jsysde
17.01.2015 um 13:56 Uhr
Wow!
Vielen Dank für die ausführlichen Infos, Hinweise und Erklärungen!

Nun kann ich mich in den nächsten Wochen direkt auf die genannten Hersteller fokusieren bzw. diese mal anschreiben, denn das mit dem Captive Portal und lokalem Breakout ist echt ein heißes Thema und einer der Hauptknackpunkte - teilweise müssen wir mit Latenzen jenseits der 120ms leben und selbst bei Standorten mit deutlich besserer Anbindung muss ich gewährleisten können, dass die User über definierte Wege/von definierten IP-Adressen kommend "nach draussen" gelangen.

Da wir die Nutzung des Gäste-WLANs an den Standorten für die privaten Smartphones und Tablets der User erlauben, wäre es außerdem Irrsinn, den ganzen Traffic erst durchs VPN in die Zentrale und vor dort ins Netz und dann wieder zurück zu schicken - das hätte definitiv einen nicht gewünschten Impact auf die verfügbare Bandbreite der Verbindungen.

Anyway, nochmals besten Dank, das hilft mir wirklich weiter!

Cheers,
jsysde
Bitte warten ..
Mitglied: sk
17.01.2015 um 14:05 Uhr
Zitat von jsysde:
Da wir die Nutzung des Gäste-WLANs an den Standorten für die privaten Smartphones und Tablets der User erlauben,
wäre es außerdem Irrsinn, den ganzen Traffic erst durchs VPN in die Zentrale und vor dort ins Netz und dann wieder
zurück zu schicken - das hätte definitiv einen nicht gewünschten Impact auf die verfügbare Bandbreite der
Verbindungen.

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
Bitte warten ..
Mitglied: stefaan
17.01.2015 um 14:09 Uhr
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
Bitte warten ..
Mitglied: jsysde
17.01.2015 um 14:35 Uhr
Mahlzeit.
Zitat von 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.
Nö, es geht um wesentlich mehr - wir haben viele und häufig Gäste, die einen Internetzugang benötigen, die ich aber nicht ins interne Netz lassen will und werde. Weiterhin Kollegen, die zu 99% nicht im Hause sind und wenn sie mal im Büro aufschlagen, wireless einen sicheren Zugriff auf interne Netzwerk-Resourcen benötigen; die haben i.d.R. nicht mal nen festen Schreibtisch. WLAN in den Konferenzräumen muss zur Verfügung stehen, Zugriff auf interne Netzwerk-Resourcen wird gefordert und muss sicher darstellbar sein usw.

Das ganze Konstrukt ist mehr als umfangreich; ginge es nur darum, den Kollegen für ihre privaten Geräte einen Internetzugang zur Verfügung zu stellen, würden wir erst gar nicht darüber nachdenken, so nen Batzen Euros überhaupt in die Hand zu nehmen.

Aber danke für den Einwurf.

Cheers,
jsysde
Bitte warten ..
Mitglied: sk
17.01.2015, aktualisiert um 16:10 Uhr
Zitat von jsysde:
Nö, es geht um wesentlich mehr - wir haben viele und häufig Gäste, die einen Internetzugang benötigen, die ich
aber nicht ins interne Netz lassen will und werde.

Hat auch niemand vergeschlagen.


Zitat von jsysde:
Weiterhin Kollegen, die zu 99% nicht im Hause sind und wenn sie mal im
Büro aufschlagen, wireless einen sicheren Zugriff auf interne Netzwerk-Resourcen benötigen; die haben i.d.R. nicht mal
nen festen Schreibtisch. WLAN in den Konferenzräumen muss zur Verfügung stehen, Zugriff auf interne Netzwerk-Resourcen
wird gefordert und muss sicher darstellbar sein usw.
Das ganze Konstrukt ist mehr als umfangreich; ginge es nur darum, den Kollegen für ihre privaten Geräte einen
Internetzugang zur Verfügung zu stellen, würden wir erst gar nicht darüber nachdenken, so nen Batzen Euros
überhaupt in die Hand zu nehmen.
Aber danke für den Einwurf.

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
Bitte warten ..
Mitglied: jsysde
17.01.2015 um 16:20 Uhr
Mahlzeit.

Berechtigter Einwand, aber:
Gäste erhalten keine Accounts im AD, das erlaubt unsere Policy nicht (keine "Container-Accounts", auch und erst recht nicht für Gäste).
Aktuell stellt das Captive Portal der m0n0wall WLAN-Vouchers in verschiedenen "Flavors" aus: 1h, 8h, 24h und das soll auch so bleiben - da die WLAN-Vouchers nicht von der IT verwaltet und ausgegeben werden, sondern von den Sekretariaten der Firmen/Abteilungen und die Gäste deren Erhalt entsprechend quittieren müssen.

Entsprechend sehe ich das auch für die Zukunft so vor, das Gäste sich ein WLAN-Voucher geben lassen müssen (ob das nun wirklich noch unterteilt werden muss in 1h/8h/24h ist ein anderes Thema), wobei in diesem WLAN-Segment keinerlei Kommunikation der WLAN-Clients untereinander gestattet wird.

Für die privaten Endgeräte der User wird selbiges WLAN-Segment verwendet werden, allerdings ohne Vouchers: Künftig müssen alle User ihre privaten Endgeräte anhand der MAC-Adresse anmelden und wir definieren eine MAC-Ausnahme auf dem Captive Portal. Dabei muss berücksichtigt werden, dass es eine ganze Menge "Roaming Users" gibt, die mal hier, mal dort an einem Standort anwesend sind und ich natürlich deren MAC-Adressen nur einmal einpflegen will.

Dieses WLAN-Segment stellt lediglich einen Internetzugang zur Verfügung, der eben über die am jeweiligen Standort verfügbare Internetanbindung abgewickelt werden soll, ggf. wird für solche Zwecke eine zweiter, von dem für das Site2Site-VPN genutzten Anschluss unabhängiger Anschluss bereitgestellt.


Per RADIUS/AD-Authentifizierung sollen die internen User sich an einem WLAN-Segment anmelden können, wenn Bedarf besteht (und der besteht häufig, aus den unterschiedlichsten Gründen). Wenn sich das durchsetzt und brauchbar/praktikabel nutzbar ist, werden für künftige Standorte/Umbauten an bestehenden Standorten sicherlich auch etliche Maschinen reine WLAN-Clients sein. Und natürlich brauchen diese User dann Zugriff auf interne Resourcen, genauso eben auf die (jeweils lokale) Internetanbindung.

Wie schon gesagt, ich muss mich in den nächsten Wochen erstmal orientieren/mit den Produkten und Lösungen der genannten Hersteller en detail beschäftigen. Wie mir scheint, sind wir wohl nicht die einzigen, die solche Herausforderungen stemmen müssen.

Vielen Dank jedenfalls, dass du soviel Hirnschmalz investierst - ich entscheide das auch mit Sicherheit nicht (allein), da werden noch ein, zwei Kollegen drüber schauen und wir disktuieren da sicherlich noch ganze Weile drüber. Daher bin ich für jede Art von "Manöverkritik" mehr als dankbar.

Cheers,
jsysde
Bitte warten ..
Mitglied: Dani
17.01.2015 um 16:40 Uhr
Moin,
Für die privaten Endgeräte der User wird selbiges WLAN-Segment verwendet werden, allerdings ohne Vouchers: Künftig müssen alle User ihre privaten Endgeräte anhand der MAC-Adresse anmelden und wir definieren eine MAC-Ausnahme auf dem Captive Portal. Dabei muss berücksichtigt werden, dass es eine ganze Menge "Roaming Users" gibt, die mal hier, mal dort an einem Standort anwesend sind und ich natürlich deren MAC-Adressen nur einmal einpflegen will.
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.

Per RADIUS/AD-Authentifizierung sollen die internen User sich an einem WLAN-Segment anmelden können
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
Bitte warten ..
Mitglied: sk
17.01.2015, aktualisiert um 18:08 Uhr
Zitat von jsysde:
Gäste erhalten keine Accounts im AD, das erlaubt unsere Policy nicht (keine "Container-Accounts", auch und erst
recht nicht für Gäste).

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.


Zitat von jsysde:
Aktuell stellt das Captive Portal der m0n0wall WLAN-Vouchers in verschiedenen "Flavors" aus: 1h, 8h, 24h und das soll
auch so bleiben - da die WLAN-Vouchers nicht von der IT verwaltet und ausgegeben werden, sondern von den Sekretariaten der
Firmen/Abteilungen und die Gäste deren Erhalt entsprechend quittieren müssen.
Entsprechend sehe ich das auch für die Zukunft so vor, das Gäste sich ein WLAN-Voucher geben lassen müssen (ob das
nun wirklich noch unterteilt werden muss in 1h/8h/24h ist ein anderes Thema), wobei in diesem WLAN-Segment keinerlei Kommunikation
der WLAN-Clients untereinander gestattet wird.

Für die privaten Endgeräte der User wird selbiges WLAN-Segment verwendet werden, allerdings ohne Vouchers: Künftig
müssen alle User ihre privaten Endgeräte anhand der MAC-Adresse anmelden und wir definieren eine MAC-Ausnahme auf dem
Captive Portal. Dabei muss berücksichtigt werden, dass es eine ganze Menge "Roaming Users" gibt, die mal hier, mal
dort an einem Standort anwesend sind und ich natürlich deren MAC-Adressen nur einmal einpflegen will.

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.


Zitat von jsysde:
Wie mir scheint, sind wir wohl nicht die einzigen, die solche Herausforderungen stemmen müssen.

Nein.


Gruß
sk
Bitte warten ..
Mitglied: Dani
17.01.2015, aktualisiert 21.01.2015
@..sk..
Nur weil im AD ein Konto existiert, muss man sich damit noch lange nicht an irgend einem Rechner im internen Netz anmelden können!
Dann hast du sicherlich für jedes Konto eine CAL gemietet/gekauft...
Peripherals, server components and network equipment on their own do not generally require a CAL (for Windows Server or otherwise).  Server to server communication does not require a Windows Server CAL (between two licensed Windows Servers).  Device CALs are intended for the clients/endpoints accessing the Windows Server (for any reason - to get an IP address, to access a file, to authenticate to AD, to access an application of any type on the Windows Server, etc.)  User CALs are intended for the same reason - but are assigned to the users using the clients/endpoints.
Gruß,
Dani
Bitte warten ..
Mitglied: sk
17.01.2015, aktualisiert um 18:25 Uhr
@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.
Bitte warten ..
Mitglied: jsysde
18.01.2015, aktualisiert um 09:36 Uhr
Moin.
Zitat von Dani:
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.
Coole Sache.
Womit realisiert?
Liesse sich da ein "Approval" einbauen, also dass die IT einmal auf "OK" klicken muss, bevor der User die Benachrichtigung erhält?

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.
Berechtigter Einwand, soweit hatte ich noch gar nicht gedacht.

Cheers,
jsysde
Bitte warten ..
Mitglied: jsysde
18.01.2015, aktualisiert um 09:43 Uhr
Moin.
Zitat von sk:
Nur weil im AD ein Konto existiert, muss man sich damit noch lange nicht an irgend einem Rechner im internen Netz anmelden können!
Ist mir bewusst, auch die technische Umsetzung dessen.

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.
Klingt wie die Realisierung eines feuchten Traums.
Da muss ich aber mal nachfragen: Basiert das auf der Theorie dessen, was ein solches System hergeben kann oder hast du sowas schon mal implementiert und produktiv im Einsatz?

Cheers,
jsysde
Bitte warten ..
Mitglied: jsysde
18.01.2015 um 09:50 Uhr
Moin.
Dann hast du sicherlich für jedes Konto eine CAL gemietet/gekauft...
Auch dies ein berechtigter Einwand - hier wäre unsererseits eine genauere Prüfung der Mehrkosten durch Lizenzen gegenüber dem Verwaltungsaufwand angesagt, was sicherlich keine einfache Aufgabe wird, aber lösbar ist.

Ich sortiere jetzt erst mal die ganzen Infos/Möglichkeiten...

Cheers,
jsysde
Bitte warten ..
Mitglied: stefaan
18.01.2015 um 11:26 Uhr
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
Bitte warten ..
Mitglied: aqui
18.01.2015 um 15:19 Uhr
für das Gast-WLAN würde sich z.B. eine Lösung mit freeradius und MySQL anbieten
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:
http://www.administrator.de/wissen/wlan-oder-lan-gastnetz-einrichten-mi ...
Für die Voucher Verwaltung:
http://www.administrator.de/wissen/voucher-für-pfsense-online-verw ...
und auch hier:
http://www.administrator.de/wissen/netzwerk-management-server-mit-raspb ...
"Workflow mit Zettlchen basteln" entfällt damit dann vollends !
Bitte warten ..
Mitglied: sk
18.01.2015, aktualisiert um 15:35 Uhr
Zitat von jsysde:
Da muss ich aber mal nachfragen: Basiert das auf der Theorie dessen, was ein solches System hergeben kann oder hast du sowas schon
mal implementiert und produktiv im Einsatz?

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
Bitte warten ..
Mitglied: sk
19.01.2015 um 22:10 Uhr
Zitat von jsysde:
> Zitat von Dani:
> 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.
Berechtigter Einwand, soweit hatte ich noch gar nicht gedacht.

Wenn es sich nur um Systeme handelt, die Mitglied im AD sind, dann braucht man keine Clientzertifikate, um das zu verhindern. Dann authentifiziert man gegen die Computerkonten - nicht gegen die Benutzerkonten.

Gruß
sk
Bitte warten ..
Neuester Wissensbeitrag
Microsoft

Lizenzwiederverkauf und seine Tücken

(1)

Erfahrungsbericht von DerWoWusste zum Thema Microsoft ...

Ähnliche Inhalte
LAN, WAN, Wireless
Hat On Networks PL500PS WLAN-Funktion? (4)

Frage von Andy1987 zum Thema LAN, WAN, Wireless ...

LAN, WAN, Wireless
Datenbankverbindung über WLAN? (5)

Frage von flyingKangaroo zum Thema LAN, WAN, Wireless ...

LAN, WAN, Wireless
WLAN Management Verteilung (5)

Frage von eyetSolutions zum Thema LAN, WAN, Wireless ...

Heiß diskutierte Inhalte
Windows Server
Outlook Verbindungsversuch mit Exchange (15)

Frage von xbast1x zum Thema Windows Server ...

Microsoft Office
Keine Updates für Office 2016 (13)

Frage von Motte990 zum Thema Microsoft Office ...

Grafikkarten & Monitore
Tonprobleme bei Fernseher mit angeschlossenem Laptop über HDMI (11)

Frage von Y3shix zum Thema Grafikkarten & Monitore ...