The school I work at currently uses Moodle as our chosen LMS for students. Moodle is linked with our School Management system to sync courses, assignments and course enrollments among other things. This greatly assists in minimising administration work, but more on this at another time…
Our school also uses Google Apps Education Edition to provide our students with Email accounts and usage of the other Google Apps services. Google provides a great LDAP sync tool that can easily sync users and groups memberships but lacks a way to sync users passwords (not secure). For this to be possible a Single Sign On (SSO) system must come into the equation. These systems can cost thousands of dollars (depending on user numbers) from 3rd party developers or require a large amount of IT admin time and server resources to perfect a solid solution. I searched long and hard for a suitable tool for this job and tried a number of solutions but none worked well enough for my liking.
At the same time that I was searching for solutions for this issue I was also browsing around for some useful Moodle plugins. This is where I came across the Moodle-Google Intergration plugin that would solve all my issues. The plugin provides a SAML based authentication method to allow users to use their LDAP credentials (LDAP must be configured in Moodle) to log into their Google Apps account. This plugin talks with the SSO feature built into Google Apps via SAML 2.0 post and the use of the generated keys and certificates for security. Users then login to Moodle and from there can access their Google Apps account.
More to come on the configuration of this plugin. Stay tuned…
The school which I currently work at has recently manufactured an initiative to allow students to bring their own wireless enabled devices to school to assist them in their educational endeavors. Students would be granted access to the school internet connection and internal student online services via the schools wireless network. The task given to me and the rest of the schools ICT department was to allow the students to have access to the mentioned resources throughout the school whilst maintaining the schools current level of security.
We currently have a very basic and limited wireless network that was primarily put in place for staff notebooks. It was easy to see that the current wireless network would not be able to handle the amount of devices that we would potentially be throwing at it. We researched a number of wireless solutions including Netgear, Cisco, Ruckus and XIRRUS. We decided to request a trial of the XIRRUS arrays as we loved the concept and were very intrigued by its design and methods of providing a wireless network solution.
A member of the XIRRUS team came to the school along with an array for us to test. We were pleasantly surprised with the initial tests in terms of coverage against our already in place wireless network. However, coverage was only one of the boxes that needed to be ticked so the array was left with us for further testing. I proceeded mapped out how I intended the configuration of the array to fit in with our current network infrastructure.
This included:
- Multiple SSIDs – We required multiple SSIDs for various reasons (eg: Staff or Student devices & Visitors).
- VLANS - The array needed to be able to provide access to different VLANs on our network by different SSIDs.
- Captive Portal w/ RADIUS Authentication – I chose to have the array authenticate using Captive Portal against a RADIUS server as this would allow us to control which users (via our Active Directory authentication directory) could access the network and keep the network safe from outside (neighbours, etc.) sources
- IP/VLAN Address Filtering – Although our switching infrastructure could handle this via ACLs the added level of security on the array itself would assist in maintaining our current level of security.
- Centralized Management – We required centralized management of the arrays that would allow us to configure/make changes to multiple or all arrays at the same time.
- Access from Any Device – The final configuration would need to be simple but secure to allow the ability for a vast range of devices to connect.
Using the XIRRUS array I was able to implement the above configuration. The XIRRUS support team assisted me through certain aspects of this process via their excellent technical support team.
The Result:
- The XIRRUS array was setup to support numerous SSIDs with different access and security configurations.
- I was able to configure the array to handle our VLAN configuration and specify the VLAN required per SSID.
- The array has a built-in customisable Captive Portal (WPR) feature. We were able create a Captive Portal page to suit the schools style and host this on the array. For this implementation I built a new RADIUS server using Windows Server 2008 and its built-in Network Policy Server (NPS). The captive portal (WPR) on the array was then set to authenticate against this server.
- I created a new VLAN for the student wireless network to segregate the network from the rest of the schools devices. This was done for security reasons as students devices could potential be crawling with harmful material. ACLs were then applied at a switching level todeny access to or from this VLAN apart from the required servers and services (ie: Internet and internal online services). The XIRRUS array is also a Layer 3 switch which allowed me to apply further IP/VLAN filtering to the wireless network on the array itself. I was able to limit the access to specific ports only on the required servers.
- XIRRUS provides software to centrally manage and monitor the arrays. I have only just started exploring this software but from what I have seen so far it is an excellent utility to have.
- The connection was setup as an 802.11 agn OPEN connection allowing any device with a, g or n wireless capabilities to connect. The Captive Portal is simply a web page built using PERL and CSS meaning any device with a modern web browser should be able to connect.
We decided that XIRRUS was for us and proceeded with the project. A site survey was completed and the stock was ordered. Two XIRRUS representatives assisted with initial installation and configuration of the arrays and we are currently in the process of deploying the XIRRUS arrays as cabling work is completed. We hope to have the network up and running throughout the school for the commencement of Term I 2010. More to come as we proceed further…
I would also like to take this opportunity to publicly thank the XIRRUS sales and support team for their excellent assitance throughout this process. I would have no problem recommended XIRRUS to any school or organizational looking to implement a complete wireless network infrastructure. We have not been able to fault the XIRRUS product (we tried hard!) or their support.
The Drop Box (Y:) is currently in test phase…
Once it has been tested and all bugs have been destroyed the plan is to provide access for all staff and students.
Direct Blog Link: Drop Box (Y:)
Part 2…
With all Mac access completely offline and LDAP authentication for some odd (and at this point unknown) reason not able to hold a constant connection, I decided to use and configure the Directory Services Active Directory (AD) plugin. I could see the advantages and disadvantages of using the AD authentication method. However, my main concern at this point was to relieve the pressure on me from the powers to be with a quick-fix solution.
The main advantages would be a single set of user credentials for all computers (Mac & PC) in the school and easy (mapped) access to the users Windows hosted home folder. The disadvantage was that with the time constraints I was unable to find a way to map the users Windows home folder, Mac home folder and possible other AFP mappings at login. The workaround I used was to create a shortcut to the servers AFP path on all the Mac computers, which allowed users to list the directories that they had access too. During the coming holiday break I will be investigating further to find a solution.
So, I bound the XServer to AD without any hassle, opened Workgroup Manager, selected AD as the search path, authenticated and the users populated from AD. My colleagues and I then went to each Mac one by one and bound them to AD using a unique name. The only problem we ran into was that AD requires that the time on the client computer be the same (or close to the same) as the Domain Controller. With the occasional hassle, we synchronized the time settings on all Mac clients to our Domain Controller, which then enabled us to successfully bind.
With that all done I am now waiting for a full class login to occur to test the server reliability and authentication method. We will be purchasing a copy of Leopard server in the not too distant future and with the installation of this server upgrade, I am contemplating rolling back to the LDAP authentication as it allows for more flexibility and customisation considering the somewhat unique options our Mac network requires.
This is definately not the last I have seen of this issue…
Imagine it, a Mac and a PC playing well together…
[kml_flashembed movie="http://youtube.com/v/ozjmJBOAWg0" width="425" height="350" wmode="transparent" /]
To be continued…
Follow Me!