This is a goal that many sysadmins aspire to. On a new person's first day on the job, they have a computing asset upon which they can work, and all of their accounts are accessible and configured so they can do their work. No friction start. Awesome.
How this worked at WWU when I was there:
- HR flagged a new employee record as Active.
- Nightly batch process notices the state-change for this user and kicks off a Create Accounts event.
- CreateAccounts kicks off system-specific account-create events, setting up group memberships based on account type (Student/Faculty/Staff).
- Active Directory
- If student: Live@EDU.
- User shows up. Supervisor takes them to the Account Activation page.
- User Activates their account, setting a password and security questions.
- Automation propegates the password into all connected systems.
- User starts their day.
It worked. There was that activation step, but it was just the one, and once that was done they're all in.
This worked because the systems we were trying to connect all had either explicit single-sign-on support, or were sufficiently scriptable that we could write our own.
I'm now working for a scrappy startup that is very fond of web-applications, since it means we don't have to maintain the infrastructure ourselves. The above workflow... doesn't exist. It's not even possible. Very roughly, and with the details filed off:
- Invite user to join Google Apps domain.
- Wait for user to accept invite and log in.
- Send invites from 3 separate web-applications that we use daily.
- Wait for user to accept all the invites, create accounts, and suchlike.
- Add the new accounts to app-internal groups.
- Send invites from the 2 web-applications with short "email verification" windows when the user is in the office and can get them.
- Add the new accounts to other app-internal groups.
The side-effect of all of this is that the user has an account before their official start-date, they don't get all of their accounts until well after 8am, and admin users have to do things by hand. Of those 5 web-apps, only 2 of them have anything even remotely looking like an SSO hook.
There is an alternate workflow here, but it has its own problems. That workflow:
- Hard create the new user in Google Apps and put into in the 2-factor authentication bypass group. Write down the password assigned to the user.
- Login as that user to Google Apps.
- Invite the user to the 5 web-applications.
- Accept the invites and create users.
- Add the new account to whatever groups inside those web-apps.
- New user shows up.
- Give user the username and password set in step 1.
- Give user the username and password for everything created in step 4.
- Walk the user through installing a Password Manager in their browser of choice.
- Walk the user through changing their passwords on everything set in steps 1 and 4.
- Walk the user through setting up 2-factor.
- Take user out of 2-factor bypass group.
This second flow is much more acceptable to an admin since setup can be done in one sitting, and final setup can be done once the user shows up. However, it does involve written down passwords. In the case of a remote-user, it'll involve passwords passed through IM, SMS, or maybe even email
That one "Account Activation" page we had at WWU? Pipe-dream.
At some point we'll hit the inflection point between "Scrappy Startup" and "Maturing Market Leader" and the overhead of onboarding new users (and offboarding the old ones) will become onerous enough that we'll spend serious engineering resources coming up with ways to streamline the process. That may mean migrating to web-apps that have SSO hooks.
You know what would make my life a lot easier now?
If more web-apps supported either OpenID or Google Login.
It's one fewer authentication domain I have to manage, and that's always good.