Free Wireless security protocols and authentication methods practice questions

A missing or duplicate Service Principal Name (SPN) is the most likely cause because the failure is isolated to one service and affects every user of that service, which is the signature of a service-side Kerberos problem. The SPN is the service's registered Kerberos name; if it is missing or registered on the wrong account, the KDC issues service tickets that the application server cannot decrypt, so authentication to that one app fails for everyone while logon and other resources keep working. Clients pointing to a public DNS resolver would prevent them from locating domain controllers at all, so logon and most domain resources would fail, not a single app. Clock drift beyond the 5-minute tolerance breaks every Kerberos ticket for that machine, producing logon failures and repeated prompts everywhere, not a failure limited to one service. Expired passwords would stop the users from logging in to Windows in the first place, but the scenario states that morning logon succeeds. When one service fails for all users and everything else works, look at the service's SPN and service-account configuration rather than at user accounts or workstations.

The modern standard UDP ports for RADIUS are 1812 for authentication and 1813 for accounting. These are the ports to memorize first for the exam. Ports 1645 and 1646 are legacy UDP ports that can appear in older gear, with 1645 for authentication and 1646 for accounting, but they are not the modern standard. Ports 88 and 464 are associated with Kerberos, where port 88 handles Kerberos authentication and 464 handles password changes, so they are unrelated to RADIUS. Ports 1701 and 1723 are associated with tunneling protocols, with 1701 used by L2TP and 1723 used by PPTP for VPN connections, not RADIUS AAA services. A helpful memory anchor is to remember 1812 and 1813 as a pair, then recall that the legacy 1645 and 1646 may still surface in older equipment. Because RADIUS relies on UDP, verifying reachability over these specific ports through firewalls is a critical troubleshooting step, since a simple ping does not confirm UDP port reachability.

The Key Distribution Center (KDC), which usually runs on a domain controller, issues the Ticket Granting Ticket (TGT) after the client sends an AS-REQ during initial logon. Inside the KDC, the Authentication Service (AS) handles this first sign-in request and returns an AS-REP containing the TGT, which acts like a wristband proving the user already passed the entrance check. The service server hosting the resource, such as a file or web server, does not issue tickets; it receives and validates service tickets that the client presents. The client workstation requests access and presents tickets, but it does not issue them, since it does not hold the shared secret keys needed to sign and encrypt tickets. A RADIUS server provides centralized AAA for network access such as Wi-Fi and VPNs, but it is not part of the Kerberos ticket-granting process. Remembering the flow helps: the client sends an AS-REQ, the KDC replies with an AS-REP containing the TGT, then later the client uses the TGT to request service tickets from the Ticket Granting Service, also part of the KDC.

The shared secret should be checked first because a mismatched or mistyped shared secret between the RADIUS client (the wireless controller) and the RADIUS server will cause the server to reject requests before it evaluates any user credentials. The shared secret is a pre-shared key that both the network access device and the server must know, and it allows the server to trust the requesting device. Since the failure affects all logins from this new device while other devices work normally, the problem is device-level trust, not user-level. Active Directory group membership would affect authorization for specific users, but it would not cause immediate rejection of every request from one device before credentials are checked. A time-of-day access restriction would only deny users outside allowed hours and would still evaluate credentials, so it would not produce blanket immediate rejections. Client device certificates matter for EAP-TLS or PEAP validation, but certificate issues typically surface during the authentication exchange, not as an instant rejection of every request from a newly added controller. Also worth confirming is that the server has the controller defined as a known RADIUS client with the correct source IP, since an unrecognized client IP can cause silent rejects.

The correct procedure is to treat the lost phone as a security event by verifying the user's identity through the organization's process, revoking the old MFA methods tied to the stolen device, and then enrolling the new device. This prevents an attacker who has the stolen phone from continuing to approve logins. Temporarily disabling MFA until a new phone arrives removes the protective layer entirely and should never be done without a record, since it leaves the account protected by only a password. Emailing backup codes to the user's personal address is dangerous because an attacker who gains inbox access would then have everything needed to bypass MFA; backup codes should be stored in an approved password manager or secure location instead. Resetting the password while keeping the existing MFA methods fails to address the actual risk, because the stolen device still holds a valid second factor that the thief could use. The key principle is that a lost or stolen authenticator device is a security incident requiring identity confirmation and revocation of the compromised factor, not a shortcut that weakens the account.

An expired RADIUS server certificate is the most likely root cause because EAP-TLS clients validate the server's certificate before sending anything; once it expires, every client on the SSID rejects the server and shows repeated prompts, and expirations happen on a date with no one touching the configuration, which matches the sudden Monday-morning start. A rotated shared secret would also break every login, but the stem says no configuration changes were made, and a secret mismatch produces silent rejects at the NAS rather than certificate prompts on the client. A few minutes of clock drift does not break certificate validation, because certificates are valid for months or years; minutes of skew is what breaks Kerberos, not TLS. Removing users from the required group would cause authorization denials for those specific accounts, not an everyone-at-once failure, and a group change is itself a configuration change. Check the certificate's validity dates in the NPS console or the server's certificate store, then renew and rebind it to the network policy.

The Access-Challenge message is sent by the RADIUS server when it requires additional steps, such as continuing an EAP exchange or presenting a certificate, before it can make a final accept or reject decision. This message is common in EAP-based flows where the authentication happens over multiple back-and-forth exchanges. An Access-Accept message is the final positive outcome that allows the user in and may include authorization attributes like VLAN assignment or role mapping. An Access-Reject message is the final negative outcome that denies access, causing the network device to block the user and display a failure. An Access-Request message is what the network access device initially sends to the RADIUS server to begin the process; it carries the username and proof of identity along with context such as the device identifier and port. Understanding the sequence helps: the client's action triggers the device to send an Access-Request, the server may respond with one or more Access-Challenge messages during an EAP conversation, and the exchange ultimately concludes with either an Access-Accept or an Access-Reject.

Investigating the settings on that specific device is the correct approach because the failure pattern points to the workstation, not the accounts. A core help desk principle for separating workstation issues from account issues is that when many users fail on one PC, you look at that device, whereas when one user fails on many PCs, you look at the account. Since the affected users can authenticate successfully on other machines, their accounts are healthy, so device-specific problems like time drift, incorrect DNS pointing to a public resolver instead of domain DNS, or a broken secure channel with the domain are the likely culprits. Resetting the password for each affected user account would be pointless and disruptive, because the accounts already work fine elsewhere. Escalating domain trust between forests immediately is premature and unrelated, since cross-forest trust failures would affect access across many devices, not a single workstation. Rebuilding the RADIUS client entry on the server applies to network access authentication for Wi-Fi or VPN devices, not to a domain logon problem on one workstation. Checking the device's time synchronization, DNS configuration, and secure channel status is the fastest path to resolution.

TACACS+ is the correct choice because it is designed for centralized device administration and separates authentication from authorization, allowing command-by-command control for administrators. This lets an organization permit a technician to run certain commands while blocking others across all managed devices. RADIUS is oriented toward network access such as Wi-Fi or VPN logins and typically combines authentication and authorization, making it less suited to granular per-command admin control. Kerberos is a ticket-based authentication protocol used for verifying identities in domain environments, but it does not provide the command-level authorization model needed for network device administration. LDAP is a directory access protocol used to query and store identity records; it can serve as a backend identity store but does not itself enforce administrative authorization or accounting on network gear. When a scenario mentions granular control over administrative commands on network equipment, TACACS+ is the anchor answer.

WPA3-Personal with AES is the correct choice because it provides the strongest modern protection when all clients support it. WPA3-Personal uses the SAE handshake, which resists offline password-guessing attacks, and AES is the recommended cipher for modern Wi-Fi. WPA2-Personal with TKIP is weaker because TKIP is a legacy cipher retained only for backward compatibility and can reduce both security and performance. WPA2/WPA3 mixed with AES+TKIP unnecessarily lowers protection by allowing older clients to fall back to weaker methods, and AES+TKIP permits the weaker cipher when it is not needed here. WPA-Personal with AES relies on the original WPA family, which is outdated and should be avoided in favor of WPA2 or WPA3. Since every device is modern, there is no reason to enable transition or compatibility modes, so the cleanest, most secure choice is WPA3-Personal with AES.