Do I need an AD account for every environment for Kerberos Authentication to AD?

cancel
Showing results for 
Search instead for 
Did you mean: 
dbiggins
Active Member II

Do I need an AD account for every environment for Kerberos Authentication to AD?

We are using Kerberos in our Alfresco 5.1.1 / Linux to AD authentication environment to assist in making the WebDav and AOS work better.  For instance, if we have a mapped drive, or use the sharepoint connectivity and we don't want to get prompted multiple times to authenticate when we are editing content, kerberos works great.  We are not using CIFS or the Share kerberos authentication at this point, so just 'AlfrescoHTTP' stuff.

Our different environments have different URLs, which means they have different principals, which means they would have different keytabs. 

Currently there is a single AD user, the 'alfrescohttp' user, but when I created the keytab file for the test environment, I had to list the principal in the 'princ'.  I thought that the creation of the keytab file with the ktpass command would _just_ generate a keytab file, but when I ran the command again mapping the production principal to the same AD user mapped in the test environment, the test kerberos environment immediately stopped authenticating, even though I hadn't moved the new 'production' keypass file anywhere.

Does that mean that for each environment (test/prod, etc...) I would need a different AD user? Would I be able to generate multiple keytab files all mapped to the same AD account?

1 Reply
keith_bailey
Partner

Re: Do I need an AD account for every environment for Kerberos Authentication to AD?

Its a bit late for you now i'm afraid, but I think the reason the authentication failed after you re-ran ktpass is because the kvno property is incremented each time in AD.  If you re-generate the keytab, you need to distribute the file to the servers that use it. Same applies if you change the password of the principal.

Regarding whether you need a different AD user for each environment ? No, you can use the same one (although I can see why people might want to split them). Just assign additional SPNs to the same identity using 'setspn -a HTTP/my.other.fqdn@MY.REALM DOMAIN\username.