Fuzzy_kiwi: UW NetID Provisioning

Kiwi

Kiwi is the UW NetID password management system. Kiwi takes passwords and securely distributes them to all the authentication systems that need them. As passwords are changed, a Kiwi master component adds that password event to its event queue. The Kiwi master then notifies a Kiwi listener component on each of the authentication systems of the new password. When all the Kiwi listeners have successfully processed the password change, then the password event is removed from the event queue. The Kiwi architecture is centered on passwords, but by extension, this means it also is the account provisioning/deprovisioning agent for UW NetIDs.

The Kiwi system by itself does not know about UW directories, nor does it know about distinctions between UW NetID types, nor even know about the uwRegID associated with UW NetIDs. It simply deals with the UW NetID value and the password associated with that UW NetID.

UWWI, of course, has one of the Kiwi listener components mentioned above, and this is how all account provisioning and password synchronization is accomplished. The UWWI Kiwi listener is called Fuzzy_Kiwi. It's called Fuzzy_Kiwi because it has some added functionality that blurs the lines beyond the Kiwi system's intentions. Fuzzy_Kiwi has some SubMan components included (see separate SubMan section), and also does some PDS whitepage queries to provision a richer UWWI user account.

The diagram above shows the relationship between all the various infrastructure components. UWNetIDs are created and managed via the "Manage my NetID" page and various UW Technology Help Desk Tools. These tools interface with a set of APIs called Mango. Mango handles all communication to the backend NetID database and other repositories.

Passwords in the NetID space are securely distributed by a service called Kiwi - the box on the upper right.  When you change your password in one of a handful of places (i.e. the Manage page, 'passwd' on Homer, Dante, or another UA host, kpasswd on any trusted Kerberos system), they send your new password to the Kiwi server, which then distributes it to the Kiwi clients (like the UW's KDC and the NETID domain controllers.)

When a UW NetID gets created for a person (using the “Get Your UW NetID”, or “newid” site), the NetID infrastructure does a couple of things: ·         

• Creates the NetID in the backend database (“Shuksan”)
• Assigns your NetID one or more categories (undergrad student, grad student, staff, faculty, alumni, etc.)
• Based on your categories, activates some basic services – including the Kerberos/Windows principal subscription

The newid site calls a Mango API to activate the subscription – using the Kerberos principal subscription example – newid tells the API what your new NetID is and what your password is.  The Mango API then passes your NetID and password off to Kiwi.  Kiwi takes it and tells all of the Kiwi clients to create a principal for your NetID with your password.  Once that’s been done, Kiwi reports back to Mango with a green light that it was finished – Mango then marks the Kerberos subscription as Active in the backend repositories.  

In the NETID domain, we have a Kiwi client.  When we get a command from the Kiwi server, we figure out what Kiwi is trying to tell us, then do a couple of things – for the example noted above, our Kiwi client creates the user account in Active Directory, and sets the password.  

The traditional model of Kiwi includes some helper processes – in our case, Kiwi will call into a .NET Framework (which we’re calling WinAuth.NetIDManagement) that has several methods to do the dirty work of manipulating Active Directory – creating the account, setting passwords, etc.

The Kiwi architecture also handles account renames. The old NetID is saved to the uwPriorNetID attribute.

When there is a known UW NetID compromise, the NetID is put through a process called disuser which from the user's perspective denies them access to UW Technology services until they contact the UW Technology help desk, correctly establish their identity, and change their password. From the perspective of Kiwi, a disuser event is simply a password change to a password unknown to the user.

The Kiwi architecture also supports the concept of a delete. Fuzzy_kiwi does not delete UWWI users when it receives a Kiwi Delete. Instead it marks the account, and resets the password so the account is unusable. This is done to prevent situations which can't be recovered from.