githubfoam · October 24, 2025 12:36
diff --git a/eduroam cheat sheet b/eduroam cheat sheet
 ------------------------------------------------------------------------------------------
 only offered eduroam for both its local community and visitors, the implications would generally be manageable but would present specific challenges, primarily related to local resource access and network control.

 1. Access to Local Resources

    Challenge: The most significant issue. Local users connecting via eduroam at their home university are often placed on a more restricted network segment (VLAN) that only allows basic internet access. This is done for security and simplicity for roaming users.

    Implication: Local staff and students would likely lose seamless access to internal resources like network-attached storage (NAS), campus-specific printers, internal applications, or certain library databases that are restricted to the local network. They would probably need to use a VPN (Virtual Private Network) to access these resources, adding an extra, necessary step to their daily workflow.
 	
 The core difference is that yalewifi (representing your university's internal network) is primarily for the local academic community, while eduroam is a secure, global network for the international research and education community to use when they travel.

 Difference Between yalewifi and eduroam

 Feature	yalewifi (Local University Network)	eduroam (Education Roaming)
 Primary User	Local students, faculty, and staff.	Visiting students, faculty, and staff from other participating institutions worldwide. Local users can also use it.
 Authentication	Authenticates directly against the local university's identity system (e.g., NetID).	Uses the user's credentials from their home institution (e.g., [email protected]). The authentication request is securely routed back to the user's home institution for verification.
 Scope of Access	Typically provides full access to local network resources (e.g., printers, internal servers, library databases, and a direct internet connection).	Primarily provides internet access at the visited campus. Access to internal resources (like printers or restricted library databases) may be limited based on the visited institution's policy, unless a VPN is used.
 Purpose	To provide primary, comprehensive network access for the university's own community.	To provide secure, seamless, and convenient Wi-Fi access for academics roaming between participating institutions globally.

 Implications if Only eduroam Existed at the University

 If your university decided to eliminate yalewifi and only offered eduroam for both its local community and visitors, the implications would generally be manageable but would present specific challenges, primarily related to local resource access and network control.

 1. Access to Local Resources

    Challenge: The most significant issue. Local users connecting via eduroam at their home university are often placed on a more restricted network segment (VLAN) that only allows basic internet access. This is done for security and simplicity for roaming users.

    Implication: Local staff and students would likely lose seamless access to internal resources like network-attached storage (NAS), campus-specific printers, internal applications, or certain library databases that are restricted to the local network. They would probably need to use a VPN (Virtual Private Network) to access these resources, adding an extra, necessary step to their daily workflow.

 2. Network Control and Policy

    Challenge: eduroam participation comes with certain global rules and policies regarding traffic filtering and logging.

    Implication: The university's IT department would have less granular control over the network traffic of its own local users compared to a dedicated internal network like yalewifi. They must adhere to eduroam's requirements, such as not filtering certain outbound ports or restricting content, which limits the ability to implement local security or compliance-driven filtering policies for internal users.

 3. User Experience and Support

    Benefit (for Roaming): Local users would have a seamless experience connecting to eduroam at the home campus, ensuring their devices are correctly configured before they travel.

    Challenge (Configuration): Initial setup and troubleshooting for eduroam can sometimes be more complex than a straightforward local Wi-Fi, often requiring specific configuration profiles or apps. Support requests for users experiencing issues with their home institution's credentials on the local network would still fall to the local IT team.
 	
 ------------------------------------------------------------------------------------------


 ------------------------------------------------------------------------------------------
 | **Aspect**                 | **YaleWifi**                                                                                                | **Eduroam**                                                                                                                                                         |
 | -------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **Ownership / Management** | Managed internally by Yale University’s IT department.                                                      | A global federation service operated jointly by national research and education networks (NRENs) and participating universities.                                    |
 | **Purpose**                | Provides secure wireless access **for Yale’s own community** (students, faculty, staff).                    | Provides secure wireless access **for visiting academics and researchers** from other institutions participating in Eduroam.                                        |
 | **Authentication**         | Uses **Yale credentials** (e.g., `[email protected]`) validated against Yale’s identity servers (LDAP/RADIUS). | Uses the **home institution’s credentials** (e.g., `[email protected]`) which are authenticated by the visitor’s home institution through a federated RADIUS trust. |
 | **Scope**                  | **Local network** — limited to Yale’s campus and administrative networks.                                   | **Global roaming service** — available in thousands of universities and research centers worldwide.                                                                 |
 | **Network Access Level**   | Usually full internal access (printers, intranet, internal file shares, etc.).                              | Usually limited to **internet-only** access, with minimal or no access to local internal resources.                                                                 |
 | **User Management**        | Managed entirely by Yale IT — users are in Yale’s directory.                                                | Managed by both home and visited institutions; relies on federated trust and encryption.                                                                            |
 | **Security Model**         | WPA2-Enterprise or WPA3-Enterprise using local RADIUS servers.                                              | WPA2/WPA3-Enterprise using federated RADIUS proxying through Eduroam hierarchy.                                                                                     |

 ------------------------------------------------------------------------------------------
 New Scenario (Yale uses Eduroam Only)

 Yale has retired YaleWifi and decided to use Eduroam for everyone, including its own students, staff, and faculty.
 Yale continues to run FreeRADIUS + OpenLDAP locally to authenticate Yale users, while also participating in the Eduroam federation.

 Authentication Flow (Eduroam-Only)

 A. Yale user on Yale campus

 Yale user connects to Eduroam using [email protected].

 The access point sends the authentication request to Yale’s FreeRADIUS server (since the domain matches @yale.edu).

 FreeRADIUS queries Yale’s OpenLDAP to validate the credentials.

 On successful validation, FreeRADIUS sends an Access-Accept message to the access point.

 The Yale user now has internet access and can also reach internal Yale resources (configured via VLANs or ACLs).



 B. Yale user visiting another university

 The user connects to Eduroam at Oxford, for example.

 The Oxford access point sends the request through Eduroam’s federated RADIUS chain.

 The request is routed to Yale’s FreeRADIUS server.

 FreeRADIUS authenticates the credentials via OpenLDAP.

 Access is granted at Oxford, typically limited to internet only, with policies enforced locally.

 ------------------------------------------------------------------------------------------
 | **Aspect**                | **Old (Two Networks)**                   | **New (Eduroam Only)**                                    |
 | ------------------------- | ---------------------------------------- | --------------------------------------------------------- |
 | **SSID**                  | YaleWifi + Eduroam                       | Only Eduroam                                              |
 | **User Directory**        | OpenLDAP (YaleWifi only)                 | OpenLDAP (Eduroam for all users)                          |
 | **RADIUS Federation Use** | Only for guests                          | Used for both local and roaming Yale users                |
 | **Access Scope**          | YaleWifi: full access / Eduroam: limited | Eduroam: unified access (can be differentiated via VLANs) |
 | **Complexity**            | Two infrastructures                      | One unified, but relies on global federation              |
 | **Dependency**            | Local only                               | Local + external RADIUS trust hierarchy                   |


 Implications of Eduroam-Only Design

 Advantages

 Simplified user experience: one SSID everywhere.

 Federated authentication enables seamless global roaming.

 Centralized identity management with OpenLDAP.

 Disadvantages

 Reliance on external Eduroam infrastructure (for routing RADIUS requests).

 Slightly increased authentication latency.

 Must use network segmentation (VLANs or ACLs) to protect internal resources.
 ------------------------------------------------------------------------------------------
 Authentication & Access Flow — Eduroam-Only Architecture

 A. Yale User on Yale Campus

 Network Components

 Yale User’s Device

 Yale Access Point (Eduroam SSID)

 Yale Wireless Controller / Switch

 Yale FreeRADIUS Server

 Yale OpenLDAP Server

 Yale Core Router and Firewall

 Eduroam Federation (for external routing)

 Internet / Cloud resources

 Internal Yale Resources (library servers, printers, databases)




 Step-by-Step Flow

 Wi-Fi Association

 Yale user connects to Eduroam SSID using credentials: [email protected].

 EAP Authentication Start

 The access point initiates a WPA2-Enterprise / EAP-TTLS (or PEAP) handshake and forwards the authentication packet to the Yale FreeRADIUS server.

 RADIUS Request Routing

 Since the username domain is @yale.edu, the access point recognizes this is a local realm.

 The RADIUS request goes directly to Yale’s internal FreeRADIUS server (no need to go up the Eduroam hierarchy).

 Credential Validation
 FreeRADIUS queries OpenLDAP via secure (LDAPS or StartTLS) connection.
 Example query:

 uid=username,ou=People,dc=yale,dc=edu

 OpenLDAP verifies the credentials (password hash check).

 Access Decision

 If credentials are valid → FreeRADIUS sends Access-Accept to the access point.

 Optionally includes VLAN assignment attributes, e.g.,

 Faculty → VLAN 10

 Students → VLAN 20

 Staff → VLAN 30

 Network Access Granted

 Access point places the user’s session into the appropriate VLAN/subnet.

 Routing and Firewall Path

 The Yale core router directs traffic to either:

 Internal Yale resources (intranet, file servers, library systems)

 Internet via the Yale perimeter firewall and NAT gateway.

 Internet Access

 The firewall allows outbound traffic (HTTPS, DNS, etc.) from authenticated VLANs.

 Traffic flows:

 User Device → AP → Switch → Core Router → Firewall → Internet




 B. Yale User Visiting Another University (Roaming via Eduroam Federation)
 Network Components

 Yale User’s Device (at Oxford, for example)

 Oxford Access Point (Eduroam SSID)

 Oxford RADIUS Server

 Eduroam Federated RADIUS Hierarchy

 Oxford’s National RADIUS Proxy

 Eduroam Global RADIUS Root

 Yale’s National RADIUS Proxy

 Yale FreeRADIUS

 Yale OpenLDAP

 Oxford Firewall and Router

 Internet



 Step-by-Step Flow

 Wi-Fi Association

 Yale user connects to Eduroam SSID at Oxford with [email protected].

 EAP Authentication Request

 Oxford access point forwards the RADIUS Access-Request to Oxford’s local RADIUS server.

 RADIUS Federation Routing

 Oxford’s RADIUS sees @yale.edu and forwards the request up the Eduroam hierarchy:

 Oxford RADIUS → Oxford NRO RADIUS → Eduroam Global RADIUS Root → Yale NRO RADIUS → Yale FreeRADIUS

 Credential Validation (Home Institution)

 Yale FreeRADIUS authenticates the user against Yale OpenLDAP over secure LDAPS.

 If valid, sends Access-Accept back through the same chain in reverse.
 ------------------------------------------------------------------------------------------

 | **Stage**      | **Local Yale User**             | **Yale User at Another University**                      |
 | -------------- | ------------------------------- | -------------------------------------------------------- |
 | Authentication | Yale FreeRADIUS ↔ Yale OpenLDAP | Yale FreeRADIUS ↔ Yale OpenLDAP (via Eduroam federation) |
 | RADIUS Path    | Direct (local)                  | Multi-hop through Eduroam hierarchy                      |
 | VLAN / Access  | Full internal + internet        | Internet-only                                            |
 | Firewall Path  | Yale firewall and router        | Visiting site’s firewall and router                      |
 | Accounting     | Local logs in RADIUS            | Sent back via Eduroam proxies                            |
 | Dependency     | Local infra                     | Global Eduroam infrastructure                            |

 ------------------------------------------------------------------------------------------
 Two Networks: YaleWifi and Eduroam

 Network Components

 YaleWifi – internal, managed by Yale IT

 Eduroam – federated, global network

 FreeRADIUS – Yale’s RADIUS server (handles 802.1X authentication)

 OpenLDAP – Yale’s internal directory (stores user credentials, e.g., students, faculty, staff)

 Federated Eduroam RADIUS hierarchy – proxies authentication for visitors and Yale users when roaming


 Authentication Flow (Two-Network Scenario)

 A. YaleWifi (local users)

 Yale user connects to YaleWifi using [email protected].

 The wireless controller or access point forwards authentication to Yale’s FreeRADIUS server.

 FreeRADIUS validates the username and password against Yale’s OpenLDAP directory.

 If authentication succeeds, the user is granted full internal access (file shares, printers, intranet).


 B. Eduroam (visiting or roaming users)

 Guest academic connects to Eduroam using [email protected].

 Yale’s RADIUS receives the request and forwards it via Eduroam’s federated RADIUS hierarchy.

 The request travels to Oxford’s RADIUS, which authenticates against Oxford’s LDAP or Active Directory.

 Yale’s RADIUS receives the “Access-Accept” message and grants the guest internet access only.



 In this setup:

 YaleWifi is tightly controlled and integrated with Yale’s internal OpenLDAP.

 Eduroam is for guests (federated authentication).

 ------------------------------------------------------------------------------------------
 To uninstall the CAT (Configuration Assistant Tool) installer from eduroam on Windows 10

 PS:
 The CAT installer itself usually configures the network and installs certificates but does not stay as a running application, so it often doesn’t show up in Programs

 Remove eduroam from Windows 
 https://servicedesk.msstate.edu/TDClient/45/Portal/KB/ArticleDet?ID=1625

 Method 1: Using Windows Settings (Recommended)
 Uninstalling the eduroam CAT Installer Configuration
 Step 1: Forget the eduroam Wi-Fi Network

 This removes saved credentials and the network profile.

    Open Settings → Network & Internet.

    Go to Wi-Fi → Manage known networks.

    Find and click on eduroam → Select Forget.
 	



 Method 2: Certificate Cleanup (if needed)
 Step 2: Remove the eduroam CAT Certificates (Optional but recommended)

    Press Win + R, type certmgr.msc, and press Enter.

    In Certificates – Current User, expand Trusted Root Certification Authorities → click Certificates.

    Look for any certificates related to eduroam, your institution, or the CAT installer (e.g., GEANT OV RSA CA 4, etc.).

    Right-click on them and choose Delete (only if you’re sure they are related to eduroam or your institution's CAT installer).

        You may also check Personal → Certificates for user-specific ones.


 For Local Machine (Admin Required):

    Run certlm.msc (as administrator: right-click Command Prompt and select "Run as administrator").

    Follow the same steps as above to remove certificates.

 Method 3: Manual Wi-Fi Profile Removal (Optional but recommended)
 If the installer created Wi-Fi profiles that weren't removed:

 Open Command Prompt as Administrator
 Type: netsh wlan show profiles
 Find any eduroam profiles listed
 Remove them with: netsh wlan delete profile name="ProfileName"


 Restart Your Computer
    Reboot to ensure all changes take effect.	
 ------------------------------------------------------------------------------------------
	------------------------------------------------------------------------------------------
	only offered eduroam for both its local community and visitors, the implications would generally be manageable but would present specific challenges, primarily related to local resource access and network control.

	1. Access to Local Resources

	Challenge: The most significant issue. Local users connecting via eduroam at their home university are often placed on a more restricted network segment (VLAN) that only allows basic internet access. This is done for security and simplicity for roaming users.

	Implication: Local staff and students would likely lose seamless access to internal resources like network-attached storage (NAS), campus-specific printers, internal applications, or certain library databases that are restricted to the local network. They would probably need to use a VPN (Virtual Private Network) to access these resources, adding an extra, necessary step to their daily workflow.

	The core difference is that yalewifi (representing your university's internal network) is primarily for the local academic community, while eduroam is a secure, global network for the international research and education community to use when they travel.

	Difference Between yalewifi and eduroam

	Feature yalewifi (Local University Network) eduroam (Education Roaming)
	Primary User Local students, faculty, and staff. Visiting students, faculty, and staff from other participating institutions worldwide. Local users can also use it.
	Authentication Authenticates directly against the local university's identity system (e.g., NetID). Uses the user's credentials from their home institution (e.g., [email protected]). The authentication request is securely routed back to the user's home institution for verification.
	Scope of Access Typically provides full access to local network resources (e.g., printers, internal servers, library databases, and a direct internet connection). Primarily provides internet access at the visited campus. Access to internal resources (like printers or restricted library databases) may be limited based on the visited institution's policy, unless a VPN is used.
	Purpose To provide primary, comprehensive network access for the university's own community. To provide secure, seamless, and convenient Wi-Fi access for academics roaming between participating institutions globally.

	Implications if Only eduroam Existed at the University

	If your university decided to eliminate yalewifi and only offered eduroam for both its local community and visitors, the implications would generally be manageable but would present specific challenges, primarily related to local resource access and network control.

	1. Access to Local Resources

	Challenge: The most significant issue. Local users connecting via eduroam at their home university are often placed on a more restricted network segment (VLAN) that only allows basic internet access. This is done for security and simplicity for roaming users.

	Implication: Local staff and students would likely lose seamless access to internal resources like network-attached storage (NAS), campus-specific printers, internal applications, or certain library databases that are restricted to the local network. They would probably need to use a VPN (Virtual Private Network) to access these resources, adding an extra, necessary step to their daily workflow.

	2. Network Control and Policy

	Challenge: eduroam participation comes with certain global rules and policies regarding traffic filtering and logging.

	Implication: The university's IT department would have less granular control over the network traffic of its own local users compared to a dedicated internal network like yalewifi. They must adhere to eduroam's requirements, such as not filtering certain outbound ports or restricting content, which limits the ability to implement local security or compliance-driven filtering policies for internal users.

	3. User Experience and Support

	Benefit (for Roaming): Local users would have a seamless experience connecting to eduroam at the home campus, ensuring their devices are correctly configured before they travel.

	Challenge (Configuration): Initial setup and troubleshooting for eduroam can sometimes be more complex than a straightforward local Wi-Fi, often requiring specific configuration profiles or apps. Support requests for users experiencing issues with their home institution's credentials on the local network would still fall to the local IT team.

	------------------------------------------------------------------------------------------


	------------------------------------------------------------------------------------------
	\| Aspect \| YaleWifi \| Eduroam \|
	\| -------------------------- \| ----------------------------------------------------------------------------------------------------------- \| ------------------------------------------------------------------------------------------------------------------------------------------------------------------- \|
	\| Ownership / Management \| Managed internally by Yale University’s IT department. \| A global federation service operated jointly by national research and education networks (NRENs) and participating universities. \|
	\| Purpose \| Provides secure wireless access for Yale’s own community (students, faculty, staff). \| Provides secure wireless access for visiting academics and researchers from other institutions participating in Eduroam. \|
	\| Authentication \| Uses Yale credentials (e.g., `[email protected]`) validated against Yale’s identity servers (LDAP/RADIUS). \| Uses the home institution’s credentials (e.g., `[email protected]`) which are authenticated by the visitor’s home institution through a federated RADIUS trust. \|
	\| Scope \| Local network — limited to Yale’s campus and administrative networks. \| Global roaming service — available in thousands of universities and research centers worldwide. \|
	\| Network Access Level \| Usually full internal access (printers, intranet, internal file shares, etc.). \| Usually limited to internet-only access, with minimal or no access to local internal resources. \|
	\| User Management \| Managed entirely by Yale IT — users are in Yale’s directory. \| Managed by both home and visited institutions; relies on federated trust and encryption. \|
	\| Security Model \| WPA2-Enterprise or WPA3-Enterprise using local RADIUS servers. \| WPA2/WPA3-Enterprise using federated RADIUS proxying through Eduroam hierarchy. \|

	------------------------------------------------------------------------------------------
	New Scenario (Yale uses Eduroam Only)

	Yale has retired YaleWifi and decided to use Eduroam for everyone, including its own students, staff, and faculty.
	Yale continues to run FreeRADIUS + OpenLDAP locally to authenticate Yale users, while also participating in the Eduroam federation.

	Authentication Flow (Eduroam-Only)

	A. Yale user on Yale campus

	Yale user connects to Eduroam using [email protected].

	The access point sends the authentication request to Yale’s FreeRADIUS server (since the domain matches @yale.edu).

	FreeRADIUS queries Yale’s OpenLDAP to validate the credentials.

	On successful validation, FreeRADIUS sends an Access-Accept message to the access point.

	The Yale user now has internet access and can also reach internal Yale resources (configured via VLANs or ACLs).



	B. Yale user visiting another university

	The user connects to Eduroam at Oxford, for example.

	The Oxford access point sends the request through Eduroam’s federated RADIUS chain.

	The request is routed to Yale’s FreeRADIUS server.

	FreeRADIUS authenticates the credentials via OpenLDAP.

	Access is granted at Oxford, typically limited to internet only, with policies enforced locally.

	------------------------------------------------------------------------------------------
	\| Aspect \| Old (Two Networks) \| New (Eduroam Only) \|
	\| ------------------------- \| ---------------------------------------- \| --------------------------------------------------------- \|
	\| SSID \| YaleWifi + Eduroam \| Only Eduroam \|
	\| User Directory \| OpenLDAP (YaleWifi only) \| OpenLDAP (Eduroam for all users) \|
	\| RADIUS Federation Use \| Only for guests \| Used for both local and roaming Yale users \|
	\| Access Scope \| YaleWifi: full access / Eduroam: limited \| Eduroam: unified access (can be differentiated via VLANs) \|
	\| Complexity \| Two infrastructures \| One unified, but relies on global federation \|
	\| Dependency \| Local only \| Local + external RADIUS trust hierarchy \|


	Implications of Eduroam-Only Design

	Advantages

	Simplified user experience: one SSID everywhere.

	Federated authentication enables seamless global roaming.

	Centralized identity management with OpenLDAP.

	Disadvantages

	Reliance on external Eduroam infrastructure (for routing RADIUS requests).

	Slightly increased authentication latency.

	Must use network segmentation (VLANs or ACLs) to protect internal resources.
	------------------------------------------------------------------------------------------
	Authentication & Access Flow — Eduroam-Only Architecture

	A. Yale User on Yale Campus

	Network Components

	Yale User’s Device

	Yale Access Point (Eduroam SSID)

	Yale Wireless Controller / Switch

	Yale FreeRADIUS Server

	Yale OpenLDAP Server

	Yale Core Router and Firewall

	Eduroam Federation (for external routing)

	Internet / Cloud resources

	Internal Yale Resources (library servers, printers, databases)




	Step-by-Step Flow

	Wi-Fi Association

	Yale user connects to Eduroam SSID using credentials: [email protected].

	EAP Authentication Start

	The access point initiates a WPA2-Enterprise / EAP-TTLS (or PEAP) handshake and forwards the authentication packet to the Yale FreeRADIUS server.

	RADIUS Request Routing

	Since the username domain is @yale.edu, the access point recognizes this is a local realm.

	The RADIUS request goes directly to Yale’s internal FreeRADIUS server (no need to go up the Eduroam hierarchy).

	Credential Validation
	FreeRADIUS queries OpenLDAP via secure (LDAPS or StartTLS) connection.
	Example query:

	uid=username,ou=People,dc=yale,dc=edu

	OpenLDAP verifies the credentials (password hash check).

	Access Decision

	If credentials are valid → FreeRADIUS sends Access-Accept to the access point.

	Optionally includes VLAN assignment attributes, e.g.,

	Faculty → VLAN 10

	Students → VLAN 20

	Staff → VLAN 30

	Network Access Granted

	Access point places the user’s session into the appropriate VLAN/subnet.

	Routing and Firewall Path

	The Yale core router directs traffic to either:

	Internal Yale resources (intranet, file servers, library systems)

	Internet via the Yale perimeter firewall and NAT gateway.

	Internet Access

	The firewall allows outbound traffic (HTTPS, DNS, etc.) from authenticated VLANs.

	Traffic flows:

	User Device → AP → Switch → Core Router → Firewall → Internet




	B. Yale User Visiting Another University (Roaming via Eduroam Federation)
	Network Components

	Yale User’s Device (at Oxford, for example)

	Oxford Access Point (Eduroam SSID)

	Oxford RADIUS Server

	Eduroam Federated RADIUS Hierarchy

	Oxford’s National RADIUS Proxy

	Eduroam Global RADIUS Root

	Yale’s National RADIUS Proxy

	Yale FreeRADIUS

	Yale OpenLDAP

	Oxford Firewall and Router

	Internet



	Step-by-Step Flow

	Wi-Fi Association

	Yale user connects to Eduroam SSID at Oxford with [email protected].

	EAP Authentication Request

	Oxford access point forwards the RADIUS Access-Request to Oxford’s local RADIUS server.

	RADIUS Federation Routing

	Oxford’s RADIUS sees @yale.edu and forwards the request up the Eduroam hierarchy:

	Oxford RADIUS → Oxford NRO RADIUS → Eduroam Global RADIUS Root → Yale NRO RADIUS → Yale FreeRADIUS

	Credential Validation (Home Institution)

	Yale FreeRADIUS authenticates the user against Yale OpenLDAP over secure LDAPS.

	If valid, sends Access-Accept back through the same chain in reverse.
	------------------------------------------------------------------------------------------

	\| Stage \| Local Yale User \| Yale User at Another University \|
	\| -------------- \| ------------------------------- \| -------------------------------------------------------- \|
	\| Authentication \| Yale FreeRADIUS ↔ Yale OpenLDAP \| Yale FreeRADIUS ↔ Yale OpenLDAP (via Eduroam federation) \|
	\| RADIUS Path \| Direct (local) \| Multi-hop through Eduroam hierarchy \|
	\| VLAN / Access \| Full internal + internet \| Internet-only \|
	\| Firewall Path \| Yale firewall and router \| Visiting site’s firewall and router \|
	\| Accounting \| Local logs in RADIUS \| Sent back via Eduroam proxies \|
	\| Dependency \| Local infra \| Global Eduroam infrastructure \|

	------------------------------------------------------------------------------------------
	Two Networks: YaleWifi and Eduroam

	Network Components

	YaleWifi – internal, managed by Yale IT

	Eduroam – federated, global network

	FreeRADIUS – Yale’s RADIUS server (handles 802.1X authentication)

	OpenLDAP – Yale’s internal directory (stores user credentials, e.g., students, faculty, staff)

	Federated Eduroam RADIUS hierarchy – proxies authentication for visitors and Yale users when roaming


	Authentication Flow (Two-Network Scenario)

	A. YaleWifi (local users)

	Yale user connects to YaleWifi using [email protected].

	The wireless controller or access point forwards authentication to Yale’s FreeRADIUS server.

	FreeRADIUS validates the username and password against Yale’s OpenLDAP directory.

	If authentication succeeds, the user is granted full internal access (file shares, printers, intranet).


	B. Eduroam (visiting or roaming users)

	Guest academic connects to Eduroam using [email protected].

	Yale’s RADIUS receives the request and forwards it via Eduroam’s federated RADIUS hierarchy.

	The request travels to Oxford’s RADIUS, which authenticates against Oxford’s LDAP or Active Directory.

	Yale’s RADIUS receives the “Access-Accept” message and grants the guest internet access only.



	In this setup:

	YaleWifi is tightly controlled and integrated with Yale’s internal OpenLDAP.

	Eduroam is for guests (federated authentication).

	------------------------------------------------------------------------------------------
	To uninstall the CAT (Configuration Assistant Tool) installer from eduroam on Windows 10

	PS:
	The CAT installer itself usually configures the network and installs certificates but does not stay as a running application, so it often doesn’t show up in Programs

	Remove eduroam from Windows
	https://servicedesk.msstate.edu/TDClient/45/Portal/KB/ArticleDet?ID=1625

	Method 1: Using Windows Settings (Recommended)
	Uninstalling the eduroam CAT Installer Configuration
	Step 1: Forget the eduroam Wi-Fi Network

	This removes saved credentials and the network profile.

	Open Settings → Network & Internet.

	Go to Wi-Fi → Manage known networks.

	Find and click on eduroam → Select Forget.




	Method 2: Certificate Cleanup (if needed)
	Step 2: Remove the eduroam CAT Certificates (Optional but recommended)

	Press Win + R, type certmgr.msc, and press Enter.

	In Certificates – Current User, expand Trusted Root Certification Authorities → click Certificates.

	Look for any certificates related to eduroam, your institution, or the CAT installer (e.g., GEANT OV RSA CA 4, etc.).

	Right-click on them and choose Delete (only if you’re sure they are related to eduroam or your institution's CAT installer).

	You may also check Personal → Certificates for user-specific ones.


	For Local Machine (Admin Required):

	Run certlm.msc (as administrator: right-click Command Prompt and select "Run as administrator").

	Follow the same steps as above to remove certificates.

	Method 3: Manual Wi-Fi Profile Removal (Optional but recommended)
	If the installer created Wi-Fi profiles that weren't removed:

	Open Command Prompt as Administrator
	Type: netsh wlan show profiles
	Find any eduroam profiles listed
	Remove them with: netsh wlan delete profile name="ProfileName"


	Restart Your Computer
	Reboot to ensure all changes take effect.
	------------------------------------------------------------------------------------------
No results found