Well I assure you it's a persistent change so you've got something modifying
this and taking it out. You should turn on auditing of the
servicePrincipalNames attribute and enable DS Access auditing on your DCs.
Thanks,
Brian Desmond
br...@briandesmond.com
c - 312.731.3132
-Original
I take it that it would be too difficult to have your developers go back and do
away with the hardcoded names?
Phillip Partipilo p...@psnet.com 7/26/2010 12:31 PM
I'm decommissioning some servers, and to ease the transition, since we have
some old code that is hardcoded with old server names,
What OS? I had to do this about a year ago on a 2003 Server and I did not
have to use the setspn tool that I recall. I did have to create a string
value at HKLM\System\CurrentControlSet\Services\lanmanserver\parameters
called OptionalNames, and put the secondary names there (each on its own
Perhaps I should note that I was only moving file shares and no Kerberized
services.
On Mon, Jul 26, 2010 at 4:08 PM, Richard Stovall rich...@gmail.com wrote:
What OS? I had to do this about a year ago on a 2003 Server and I did not
have to use the setspn tool that I recall. I did have to
Your machine wouldn't happen to be a domain controller, would it?
See the last 4 comments to a very interesting article.
http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx
On Mon, Jul 26, 2010 at 3:31 PM, Phillip
Admin Issues
Subject: Re: setspn persistence
Your machine wouldn't happen to be a domain controller, would it?
See the last 4 comments to a very interesting article.
http://blogs.technet.com/b/askds/archive/2008/05/29/kerberos-authentication-problems-service-principal-name-spn-issues-part-1.aspx
