If you have a visitor to Cornell who needs to use their own computer on a Cornell University network, the computer needs to be registered as required by the Network Registry policy. Registration is similar to that of Cornell computers, but visitors who do not have a Cornell NetID may identify themselves by their email address.

Departments have several options for allowing visitors' computers to access their networks.

• Not allow visitors' computers on the network at all.
• Require visitors' computers to be pre-registered by the departmental network administrator.
• Allow visitors who have registered elsewhere on campus (for example, at another department or a public port).
• Allow visitors to register themselves, as long as they know the department's passcode (which you can supply to expected visitors).
• Allow visitors to register themselves freely.

Given the range of options, the network administrator should consult with others in the department as appropriate about what best suits local needs, and then make sure that faculty and staff who interact with visitors are informed of the chosen approach.

Registrations made through self-registry are valid for a maximum of 21 days during each semester. (The registration records at reset on January 1 and July 1.) Registrations made by the network administrator are not subject to those limits.

Note: For visitors who need more than 21 days, the registration can be extended by:

• Talking to the sponsoring department host about obtaining a Sponsored NetID. 
• Having the network administrator extend the registration, subject to departmental rules.

If the visitor is using RedRover, the registration can be extended by obtaining a Sponsored NetID. The IT Service Desk may also be able to provide an emergency 5-day extension. 

Host Registrations for Visitors

A host registration may have an email address listed as the owner. There are three restrictions:

• There must be visitor information on file about the email address (see below).
• A visitor's email address may not be a cornell.edu email address.
• The host registration must have an expiration date set.

Configure Subnets for Visitor Registration

Network administrators can choose to keep visitor registration for their subnets in their own hands, or to allow visitor self-registration, which enables visitors to come and go with no network administrator intervention. In all cases, network administrators receive the normal notification of host registrations and changes. See the procedures below.

Configure a Subnet for Visitor Self-Registration

1. Connect to the DNSDB subnet page.
2. Visitor Pool Access set to YES. In conjunction with a dynamic pool, this means that any computer with with a regular or visitor registration will have access, even if the initial registration was on another subnet.
3. Decide how you want to use a passcode.
   • To allow anyone to self-register as a visitor, leave Visitor Registration Passcode blank.
   • To regulate who can self-register as a visitor, in the Visitor Registration Passcode field, set a passcode. You will also need to distribute the passcode appropriately.
   • To allow visitors, but not allow registration on the subnet, in the Visitor Registration Passcode field, set a passcode, but do not distribute the passcode.

Typical scenario for self-registration:

1. Visitor gets on network, is prompted with Cornell Network Registration.
2. Visitor fills out form. Information about the visitor and their computer is filed, and the network is reconfigured.
3. Visitor reboots, gets on network (no longer prompted for Cornell Network Registration).
4. At this point, the visitor can use their computer for the time they specified when they registered, up to 21 days per semester.
5. The registration expires.

Configure a Subnet for Visitor Registration by Network Administrator Only

Note: Network administrators can register computers for visitors. Registrations entered by network administrators are not subject to the 21-day limit set for self-registrations.

A local network administrator always registers guests directly in DNSDB, and does not want any other guests on the department's network(s).

1. Check that the record for the visitor exists in the visitor.cgi list.
2. Connect to the DNSDB subnet page.
3. Visitor Pool Access set to NO.
   May still have a dynamic pool that accepts regular CU registrations.
4. Connect to the DNSDB host page.
5. Add the visitor registration.

About Visitor Registry

A registry of visitor email addresses is kept, including all email addresses used as primary users of computers. The following information is stored in the registry:

• Name
• Email address
• Cornell department or unit visited
• Length of visit
• Date of data entry
• Source of data (NetID, etc.)

Any network administrator across campus can update a visitor's information. This means network administrators can maintain data for visitors who are using the facilities of multiple departments. Visitor information is not overwritten. A log of changes is kept along with information about which network administrator made each change.

Subnet Options that Control Visitor Access

A subnet controlled by CIT DHCP has the following options, displayed and set on the DNSDB subnet page.

1. Visitor Pool Access: Allow/disallow visitor access to the subnet. For example, if the subnet has a dynamic pool that allows 'known' addresses, and Visitor Pool Access is set to allow, then a computer registered to a visitor (that is, the primary user is indicated by an email address) can use the pool. If set to disallow, such a user will be treated as unknown.
2. Visitor Reg Passcode: Setting a passcode means a visitor cannot self-register without the passcode, allowing departments to select who they allow to register. If visitors are allowed, and the subnet has a registration pool, then visitors can register, under the control of the subnet's passcode. If no passcode is set, registering visitors are not prompted for a passcode and anyone can register as a visitor.