Standard for Authentication, Authorization and Auditability
All new applications are required to use LDAP for account control and authentication.
Where alternatives are possible, no transmission of passwords in clear text is allowed. All authentication will use encrypted transmissions. Projects will be established to eliminate all processes that cannot.
The authoritative source for students for LDAP is SIS, for employees (both faculty and staff) is HRS, for alumni is ADS. If someone is not in SIS or HRS, they will not be identified in LDAP as a student, faculty or staff, and are not entitled to services for those employeetypes.
Access logs for all servers, proxies and network resources shall be kept a minimal of 30 days.
For the Fall 2002, the Marist network will be protected by several methods. MAC address based authentication will be enforced by Cisco User Registration Tool (URT) and Cisco VLAN Policy Server (VPS).
Public labs (DN258, LT135 and Library E-scriptorium) will be configured to use a web proxy server that will require Marist account code authentication to use web resources off the Marist campus.
There is a Cisco PIX Firewall that will prohibit inbound non-Marist access to most of the Marist campus, except for the DMZ. All Marist machines will have unrestricted access to the Internet, except for certain services that have been blocked for some time now, such as Napster.
The Cisco PIX firewall will allow Marist machines to connect into the DMZ with little restriction, and non-Marist resources will be able to connect into the DMZ for specific documented resources.
The Cisco switches in the DMZ each have a Network-based IDS blade installed. Minimal monitoring is in effect, and will be evaluated during the Fall. IDS blades for the Cisco switches in the core part of internal network will be installed when available this Fall.
All Windows servers, and Intel-based Linux machines will have Tripwire for servers installed, which will be centrally managed. All machines in the DMZ will have SNMP configured for monitoring by Operations.
Current MAC address access
Current security on the Marist network is based almost exclusively on the Media Access Control (MAC) address. The MAC address is a unique identifier that is burned into the Network Interface Card (NIC) by the manufacturer. If a MAC address fails authentication, a workstation will not be able to access IP-based resources, including the Internet. This will be accomplished by placing them into a virtual LAN (VLAN) that cannot access such resources. Every machine will be tracked by person responsible for the machine. Machines not assigned will be removed from the network.
Cisco promotes logon authentication as a method of VLAN selection. There are some limitation issues that Marist is currently working on with Cisco. For example, Cisco
Once a NIC has been allowed onto the network, an IP address is requested via Dynamic Host Configuration Protocol (DHCP) by sending its MAC address to a DHCP server which also maintains a table of valid MAC addresses, and gives an IP address for known MAC addresses. Without a valid IP address, no computer will be able to use the Internet or most services on the local campus. There are also various tools used to scan for other problems on campus.
All unrestricted public access areas labs on campus, including Donnelly and the library, are allowed unrestricted access to local applications in these areas, such as Word, Excel and other desktop applications, but are forced to logon authenticate for web surfing using a web proxy server, similar to what is done for off campus access to the library resources. Access from other areas on campus, including residence halls will continue to be MAC-address based.
Long Term Goal
The long-term goal of UserID and passwords will be a single Enterprise-wide sign-on to a central Kerberos system. Once a user is signed-on to the central system, the user will be automatically authenticated to all systems at Marist. This single logon requires Enterprise-wide evaluation and planning due to the complexity and management of a central authentication system. The path to this solution will be to require multiple sign-on to the central authentication system. Since Kerberos authentication is still not available for most of the client systems, we will use the central LDAP authentication as a step in that direction. Many of the current systems use LDAP authentication as their means of authentication. All new systems will use LDAP authentication. Marist can then more easily migrate to Kerberos authentication in the future.
We will evaluate authentication systems, and look to expand the authentication for this coming year to include broader logon authentication moving towards the longer-term goal of full authentication as described above. Our goal is to achieve full authentication by August 2004.