Central Web SSO server.

Assign web logins to Active Directory groups on one page and have every member’s PC fill them in automatically — an optional IIS add-on for CodeB SmartLogin, with per-group DPAPI-NG encryption.

CodeB Credential Provider V2 · User manual

In short

The CodeB Web SSO Server is an optional enterprise add-on that lets admins assign web logins (website, user name, password, optional OTP) to Active Directory groups on one web page. Every member of a group gets those logins on every PC running CodeB SmartLogin, filled in automatically and never shown to the user. CodeB SmartLogin works exactly as before without it; only enterprises that want to manage web logins centrally install it.

What is the CodeB Web SSO Server?

The CodeB Web SSO Server is a small IIS web application that stores web logins centrally and hands them to the PCs of the people who should have them. An administrator assigns each login to an Active Directory group; every member of that group then receives the login on every PC with CodeB SmartLogin. The central logins are used next to each user’s own Web SSO logins, the user cannot change or delete them, and they never overwrite the user’s own.

It is optional. CodeB SmartLogin’s per-user Web SSO works exactly as before without the server; only organisations that want central control install it.

How does it work?

  • An admin adds a login on the server’s web page and assigns it to an AD group (with website, match mode, user name, password, optional OTP secret and auto-submit).
  • Every PC with CodeB SmartLogin downloads the logins for the groups the signed-in user belongs to and fills them in on the matching sites.
  • Central logins are not shown in the user’s own Web SSO manager, so the user never sees the passwords.
  • Remove a person from the group and the logins disappear from their PCs — at the latest after about 5 minutes and a new Windows sign-in (group membership changes take effect on a new sign-in).

What do you need?

RequirementDetail
ServerWindows Server with IIS, .NET Framework 4.7.2 or newer, joined to the domain.
KDS root keyThe domain needs a KDS root key (also used for gMSA). A domain admin runs it once per forest: Add-KdsRootKey -EffectiveImmediately (allow up to 10 hours of replication in larger domains). The setup checks it.
HTTPSAn HTTPS binding is recommended.
PCsWindows PCs running CodeB SmartLogin, pointed at the server with two registry values.
Availability

The server component (CodeBWebSSOServer.zip, with a README.txt install guide in the root of the zip) is an optional enterprise add-on that ships with the CodeB SmartLogin beta downloads. For an evaluation key or help, contact info@codeb.io.

How do you install the server?

  1. Unzip CodeBWebSSOServer.zip into a folder, for example C:\inetpub\CodeBWebSSO.
  2. In IIS create a site or application for that folder. Application pool: .NET CLR v4.0, integrated pipeline.
  3. Authentication: enable Windows Authentication and keep Anonymous Authentication enabled.
  4. Give the application pool identity write access to the App_Data folder, and remove read access for Users / Authenticated Users there. The stored logins are encrypted for the server itself, so only the pool and administrators should be able to read the folder. The setup checks show the exact icacls command.
  5. Open the site in a browser. It sees that it is not configured and starts the setup wizard:
    • Checks: .NET version, App_Data writable, domain member, encryption, KDS root key, HTTPS.
    • Setup code: to prove you administer the server, open App_Data\setup-code.txt on the server and type the code (not needed when the browser runs as elevated local admin). The file is removed when setup finishes.
    • Admin group: the AD group whose members may manage the logins (default Domain Admins; a dedicated group is recommended). You must be a member yourself.
    • API key: shown once — copy it.
    • Done.
Built-in manual

The server has its own manual at Manual.aspx (the “Manual” link in the header of every page, readable without sign-in, even before setup). It covers install, the setup wizard, PC configuration, managing logins, security, logs and troubleshooting.

Point the PCs at the server

On the PCs set two registry values (REG_SZ, best with a Group Policy registry preference). Without these values a PC does not use the server. See the full registry reference.

Registry value (REG_SZ)Set to
HKLM\SOFTWARE\WOW6432Node\CodeB\WebSSOServerThe site URL, e.g. https://sso.example.local
HKLM\SOFTWARE\WOW6432Node\CodeB\WebSSOServerApiKeyThe API key shown during setup

Add and manage logins

On the server’s web page use Add login and set: AD group, label, website, match mode, user name, password, optional OTP and auto-submit. To change the admin group or roll the API key later, use Settings on the start page (the PCs then need the new key). Every change is logged with who made it.

Match modes decide when a login is offered: exact host, wildcard (subdomains) or exact origin.

Security & encryption

  • Each group’s logins are encrypted with DPAPI-NG for that AD group. Only members of the group can open them, on their own PC.
  • The PCs use an API key to download the logins. The key alone reveals nothing: the server only hands out encrypted data.
  • On the server the logins are encrypted for the server itself; the setup stores only a hash of the API key. Logs never contain passwords.
  • Admin pages require Windows sign-in and membership of the chosen admin group; every change is logged with who did it.
Honest note

Every member of a group can technically open that group’s logins on their PC — that is how the PC fills them in. Treat a central password as known to all members of its group; for very sensitive accounts use a small group.

Per-user encryption of the local Web SSO store

Independently of the server, the file that holds a user’s own Web SSO logins on a PC is now encrypted with DPAPI-NG for that user. On the PC where it was written, only that Windows user can open it (also offline); for domain users it is additionally encrypted for the user’s domain account, so it opens on other domain PCs too (useful with RemoteDataFolder and roaming profiles). Another user, an admin copying the file, or a stolen disk cannot read the passwords. Nothing needs to be set up — old files are read as before and saved in the new format at the next save, and if a file cannot be opened CodeB never overwrites it.

Behaviour & offline

  • Server down or PC offline: the PC uses the last downloaded (still encrypted) copy. Nothing stops working.
  • How fast changes arrive: at the latest after about 5 minutes, when the Web SSO component looks again.
  • Health check for monitoring: https://<server>/api.ashx?action=health.

Troubleshooting

A PC does not receive central logins

Check the two registry values (WebSSOServer URL and WebSSOServerApiKey), that the signed-in user is in the assigned AD group, and that the user signed in again after the group change. Group membership changes take effect only on a new Windows sign-in.

The setup wizard asks for a setup code

Open App_Data\setup-code.txt on the server and type the code, or run the browser as an elevated local administrator. The file is removed once setup finishes.

Frequently asked questions

Is the Web SSO server required?

No. It is an optional enterprise add-on. CodeB SmartLogin and its per-user Web SSO work exactly as before without it; install it only to manage web logins centrally for AD groups.

Can the user see or change central passwords?

Central logins are not shown in the user’s Web SSO manager and cannot be changed or deleted by the user. However, every member of a group can technically open that group’s logins on their PC, so treat a central password as known to all members of its group.

How quickly does removing someone from a group take effect?

The logins disappear from their PCs at the latest after about 5 minutes and a new Windows sign-in. Group membership changes need a new sign-in to take effect.

What happens if the server is down?

The PC keeps using the last downloaded (still encrypted) copy of the logins, so nothing stops working. For monitoring, the server exposes a health check at https://<server>/api.ashx?action=health.

Stuck on a step?

A real engineer reads every support email. Send the log files from the troubleshooting chapter and we usually answer within one business day.