Unpad Wifi Windows

UnpadAccess on Windows (EAP-TLS)

UnpadAccess is Universitas Padjadjaran's campus Wi-Fi. It authenticates with WPA2-Enterprise + EAP-TLS: a per-device client certificate, issued after the device's MAC address is registered. There is no password.

Two facts drive almost every failure, and they are worth internalizing before touching anything:

1. Authorization is bound to the MAC address captured at registration time. Any MAC randomization, or a different adapter than the one registered, means the RADIUS server rejects a device whose certificate is otherwise perfect.
2. Association and internet access fail independently. A device can complete 802.1X, get a DHCP lease, and route packets, yet still have no usable internet because name resolution is broken. Diagnosing these as one problem wastes a lot of time.

Workflow

1. Register the device and get the certificate

Registration must happen from the device itself — it captures that device's MAC.

• Connect to the open SSID UnpadAccessRegistration.
• Open https://goah.unpad.ac.id, log in with the PAuS ID.
• Click Daftarkan Perangkat, enter a device name (letters, digits, spaces; max 16 characters), confirm the OS, then Simpan Data Perangkat.
• Download the .p12. The portal displays its import password on the same page.
• Quota is 5 devices per PAuS ID.

The user must type their own PAuS password and any CAPTCHA. Do not enter credentials on their behalf.

2. Import the certificate correctly

Double-click the .p12, choose Current User, supply the password from the portal, and let the wizard place certificates automatically.

Automatic placement matters. The bundle contains a client certificate plus the full CA chain, and each part has to land in a different store. Verify rather than assume:

Get-ChildItem Cert:\CurrentUser\My | Where-Object { $_.Issuer -match 'Padjadjaran' } |
  Format-List Subject, NotAfter, HasPrivateKey
Get-ChildItem Cert:\CurrentUser\Root | Where-Object { $_.Subject -match 'Unpad Root CA' }
Get-ChildItem Cert:\CurrentUser\CA   | Where-Object { $_.Subject -match 'Padjadjaran' }

A healthy install shows the client certificate in My with HasPrivateKey: True, the root CA in Root, and the intermediates in CA. If everything landed in My, chain validation fails — reimport.

Certificates are typically valid for about three months. Check NotAfter early; an expired certificate produces the same silent failure as a missing one.

3. Create the Wi-Fi profile

The documented path is to click the SSID and pick a certificate from the dialog. That dialog is the single most common place people get stuck — it frequently shows an empty certificate list.

Deploying a profile directly bypasses it entirely and is far more reliable. Use assets/UnpadAccess.xml from this skill:

netsh wlan add profile filename="UnpadAccess.xml" interface="Wi-Fi" user=current

The profile encodes the settings that matter: EAP-TLS (type 13), user credentials, server validation disabled, and — critically — enableRandomization: false.

Then connect:

netsh wlan connect name="UnpadAccess" interface="Wi-Fi"

4. Verify layer by layer

Check in order, because each layer failing looks different:

netsh wlan show interfaces | Select-String "State|SSID|Authentication"
netsh interface ipv4 show config name="Wi-Fi"
Test-Connection 8.8.8.8 -Count 2
Resolve-DnsName google.com
Invoke-WebRequest "http://www.msftconnecttest.com/connecttest.txt" -UseBasicParsing

Interpreting the result:

Finally, forget UnpadAccessRegistration so the device stops drifting back to the registration network.

Failure modes worth knowing

DNS overridden by a static resolver. The highest-value check on this platform. If someone has previously hardcoded a public DNS server on the adapter, it silently overrides what the campus DHCP offers. The campus network may block outbound DNS to public resolvers, so resolution dies while ICMP still works — producing a device that pings 8.8.8.8 happily and resolves nothing.

netsh interface ipv4 show dnsservers name="Wi-Fi"

Statically Configured DNS Servers is the tell; DNS servers configured through DHCP is healthy. Reset it — this requires an elevated shell, and it fails silently without one, which makes it easy to believe you fixed something you did not:

netsh interface ipv4 set dnsservers name="Wi-Fi" source=dhcp
netsh interface ipv6 set dnsservers name="Wi-Fi" source=dhcp
Clear-DnsClientCache

Confirm the setting actually changed before concluding anything. Also note a stale DHCP lease can keep reporting the old resolver — reconnect and re-check before drawing conclusions about what the network hands out.

Clock skew. TLS rejects certificates outside their validity window, and Windows expresses this by showing an empty certificate picker rather than an error. Ensure automatic time and UTC+07:00, then reboot.

MAC randomization. Windows can randomize per network. The supplied profile disables it; verify with netsh wlan show profile name="UnpadAccess".

Scan list looks empty. While associated to another network — especially a phone hotspot — some adapters report only that network. Disconnect first, then scan, or you will wrongly conclude the campus SSIDs are out of range.

Beware of split DNS. On campus, unpad.ac.id resolves to an internal address. That is expected and not a fault.

Resources

• assets/UnpadAccess.xml — deployable EAP-TLS profile.
• scripts/wifi-watchdog.ps1 — monitors real connectivity and falls back to another SSID after a sustained outage. Useful while testing, since it checks ICMP → DNS → HTTP rather than ping alone. Ping alone gives false positives here: 8.8.8.8 answers on UnpadAccess even when the connection is unusable.
• references/troubleshooting.md — extended diagnostics and official links.