AD FS 3.0 Event ID 364 while creating MFA (and SSO)

There are a couple things you can do with Google Apps.

You can setup a SAML server connected to your AD network and then setup Google to authentication your Google Apps access against the SAML server. We have used a php application called simpleSAMLphp because we already have servers setup to run PHP and we have developers with php skills. The drawback of using a SAML solution alone is that you can only login to accounts through the web. This means you can't access your mailbox through imap/pop, and you can't login to Google talk with any old XMPP client.

Using SAML does not automatically create accounts in the Google Apps domain. You also will probably need a tool that will synchronize accounts for that you can use the Google Apps Directory sync tool. This will allow you to create accounts, but it still will not sync passwords by default because the Windows Password hashes are not reversible and Google can't do anything with them.

It is possible to use something like PasswdHk to intercept password changes in your AD and then store the password in a format (unsalted sha1) that the Google directory sync utility can use to set the Google Apps passwords. But this does add a bit of security risk since Google will only accept unsalted md5 or sha1 password hashes through its Provisioning API, and to sync with Google, you basically must store these hashes. If you are to use this, it is very important to keep these hashes secure.

Hmmph. You had me all excited about SAML until the bit about imap/pop. That'd kill all the folks using windows mobile and blackberry clients, wouldn't it? Any clever alternatives there?

If you are willing to accept the risk of storing the password hashes then are able to combine the SSO and the directory syncing together to get a working system.

As an alternative someone could develop a Intranet portal where users in your domain would go to initialize their Google account and set the password for the Google account. I had considered developing something like this, but couldn't get my coworkers to agree that it was the way to go.

The basic idea is this, build a webapp that

• Lives on your intranet and authenticates against your active directory
• Has a function that will take the username and password that the user used to login to the intranet site and get any other information you need from the AD, and then use the Google Provisioning API to add/update the users account.

Building the tool really shouldn't be too difficult, I had estimated to hack out something basic it would only take 12-16 hours of development time. The advantage of this solution is that it gives you 100% Google Apps functionality, the downside is that it somewhat inconveniences the end-user.

If I'm interpreting the error right, I think it means that you have an old version of a key in /etc/apache2/httpd.keytab. Every time the key is changed for a Kerberos principal via kadmin, the version number is incremented and older versions of that key are invalidated.

The kinit command/login only shows that the host key inside of /etc/krb5.keytab is intact. This does not necessarily mean that the kvno inside of httpd.keytab is valid and you will need to check it against the KDC.

Start a kadmin session against your KDC and invoke getprinc <principalname>. Look for "Key: vno", this tells you what the KDC considers to be the version number. If the KDC has a more recent version of the key, you need to re-export this key to the host in question. I would go ahead and check the validity of all the keys in /etc/krb5.keytab while you're at it just to make sure there aren't any other time bombs lurking around.

Hopefully this helps!