Projects: Connection Process

Old Connection Process

Students would sign up for Internet access on Cyberbear. This would enter them into the university's Banner system, which would take care of billing them. When they arrived at school, they would check out a DirectConnect CD. This CD would install software to help protect the student's PC and the university network. Once the student had finished installing the software, they were given a 'verification code', which they would then copy to a registration form. These forms were turned in to hall secretaries, who would deliver them to the building's RTA. He or she would then enter the student's information into the DirectConnect database, then activate the ethernet port in the student's room.

Interim Connection Process

This process was used in my second year as an RTA. It was similar to the process outlined above, except that there was a system in place for students to enter their own information. Then the RTAs for each building would check who had registered and enable their ports. This put the data entry into the students' hands, which made things easier for DirectConnect staff, but it still relied on data provided by students and still required many, many setup CDs to be burned.

New Connection Process

Students would sign up on Cyberbear as before. This information was pulled on a daily basis from a custom Banner query. One of the DirectConnect supervisors would then pull the information from the Banner server and enter it into a custom script on the DCOHome, which would enter the student into the DirectConnect database. At this time they would also enable the ethernet port in each student's room. Once the student arrived at the university, they would simply plug their computer into the network. The computer would request an IP address from Yeti, our custom DHCP server. It would check the MAC address of the requesting computer against the DCO database. Seeing an unrecongized MAC address, Yeti would send back an IP address on the 'dirty' IP space. This would include DNS information that pointed to Yeti. When the student requested a web page from Yeti's DNS server, Yeti would send its own IP regardless of the URL the student request. This would redirect the student to a custom setup webpage with all the downloads necessary to secure the student's computer and the UM network. Once the student installed this, they would run <PROGRAM X>, which would verify that everything was installed. It would notify the DCO server, which would then flag the student as clean. Finally, their IP address would be refreshed and they would get an address on the 'clean' network with a legitimate DNS server.