computer account change password with Windows 2008 domain
Julio Cesar Parra/Mexico/IBM
jcparra at mx1.ibm.com
Tue Apr 1 19:15:07 EDT 2008
Hello , I'm interested in the hotfix too, I have the same problem
recognizing the service principals configuring a System i to use kerberos,
Could you please let me know how to get the hotfix to test it ?
"Tim Alsop" <Tim.Alsop at cybersafe.com>
Sent by: kerberos-bounces at mit.edu
"Wilper, Ross A" <rwilper at stanford.edu>, "Russ Allbery" <rra at stanford.edu>
Srinivas Cheruku <srinivas.cheruku at cybersafe.com>, kerberos at mit.edu
RE: computer account change password with Windows 2008 domain
Thankyou. If a hotfix is available, our partner support people at MS
will be able to get us same hotfix to test.
From: Wilper, Ross A [mailto:rwilper at stanford.edu]
Sent: 01 April 2008 22:44
To: Russ Allbery; Tim Alsop
Cc: kerberos at mit.edu; Srinivas Cheruku
Subject: RE: computer account change password with Windows 2008 domain
Our case SRZ080225000456 is open for the Windows 2008 KDC being unable
to authenticate any account with a "/" in the principal name. On this
case, we have been issued a private hotfix that appears to resolve the
issue. The hotfix is now in review for public release.
Our case SRZ080306000400 is open for the Windows 2008 LDAP server not
being able to negotiate QOP for SASL binds over SSL with OpenLDAP. This
case is still in the troubleshooting phase.
From: Russ Allbery [mailto:rra at stanford.edu]
Sent: Tuesday, April 01, 2008 2:36 PM
To: Tim Alsop
Cc: kerberos at mit.edu; Srinivas Cheruku; Wilper, Ross A
Subject: Re: computer account change password with Windows 2008 domain
Ross, could you give Tim our reference numbers for our Microsoft bug
reports that we filed as part of Guest? They're running into one of the
same issues, and I figure the more the merrier on the complaining.
"Tim Alsop" <Tim.Alsop at CyberSafe.Com> writes:
> That's great information, thanks.
> We are using Kerberos set password protocol to change/set the computer
> account password, but since the SPN used contains a / I suspect we are
> experiencing the same issues you described.
> If you have any reference numbers for your problems, then I would like
> to mention them to MS when I talk to them tomorrow.
> -----Original Message-----
> From: Russ Allbery [mailto:rra at stanford.edu]
> Sent: 01 April 2008 22:17
> To: Tim Alsop
> Cc: kerberos at mit.edu
> Subject: Re: computer account change password with Windows 2008 domain
> "Tim Alsop" <Tim.Alsop at CyberSafe.Com> writes:
>> We have discovered a problem when we try to set/change password for a
>> computer account in AD on Windows Server 2008. The computer account
>> created so we can use it for a service/application, and the key is
>> created from it's password (randomly generated) and extracted into a
>> table file.
>> Our code is able to create the account (authenticating to AD using
>> SASL/GSS/Kerberos) but when we try and set the computer account's
>> password to a random value, the request is rejected, so it looks like
>> on Windows 2008 has some changes which stop password changes for
>> computer accounts, or maybe something which is stopping changes to
>> passwords for accounts that use a principal name such as
>> name/fqdn at REALM.
> You don't say here *how* you're changing the password, but there are
> Active Directory bugs in Windows 2008 that you may be running into:
> * Authentication to Active Directory using a principal that contains a
> slash (such as service/foo) from a keytab generated by the Windows
> is broken in Windows 2008. It works fine if there is no slash in
> principal. Microsoft has identified this as a bug and is working on
> * Microsoft broke password changes via the LDAP protocol with SASL
> binds in Windows 2008. In Windows 2003, provided that you didn't
> negotiate an SASL privacy layer, you could connect via TLS and
> authenticate with GSSAPI and query or set the password attribute
> directly. In Windows 2008, this no longer works; you always get the
> error from the server that you are not permitted to negotiate a
> layer when using TLS, even though you're not trying to. We've
> filed this as a bug.
> In both cases, if you have a support contract with Microsoft and this
> problem that you're running into, please independently open your own
> the more customers they know this affects, the more likely we'll get a
Russ Allbery (rra at stanford.edu)
Kerberos mailing list Kerberos at mit.edu
More information about the Kerberos