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" <[EMAIL PROTECTED]> writes: > Russ, > > 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. > > Thanks, > Tim > > -----Original Message----- > From: Russ Allbery [mailto:[EMAIL PROTECTED] > Sent: 01 April 2008 22:17 > To: Tim Alsop > Cc: [email protected] > Subject: Re: computer account change password with Windows 2008 domain > > "Tim Alsop" <[EMAIL PROTECTED]> 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 is >> 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 > key >> 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 > AD >> 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/[EMAIL PROTECTED] > > You don't say here *how* you're changing the password, but there are two > 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 > tool > is broken in Windows 2008. It works fine if there is no slash in the > principal. Microsoft has identified this as a bug and is working on a > fix. > > * Microsoft broke password changes via the LDAP protocol with SASL > GSSAPI > binds in Windows 2008. In Windows 2003, provided that you didn't try > to > 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 > privacy > layer when using TLS, even though you're not trying to. We've already > filed this as a bug. > > In both cases, if you have a support contract with Microsoft and this is > a > problem that you're running into, please independently open your own > bug; > the more customers they know this affects, the more likely we'll get a > hot > fix. -- Russ Allbery ([EMAIL PROTECTED]) <http://www.eyrie.org/~eagle/> ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
