computer account change password with Windows 2008 domain

[Tim Alsop]

Michael,

I have just been reminded/corrected that our product actually uses kpasswd protocol to change password, not ldap change password - sorry for any confusion caused by this mistake. This is perhaps why it works for us, but not for you. Maybe you could also use kpasswd ?

Anyway, perhaps the info in my last post helps and this is related to a domain policy setting in some way ?

Good luck,
Tim

-----Original Message-----
From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On Behalf Of Tim Alsop
Sent: 07 January 2009 15:20
To: Michael Engemann; kerberos at mit.edu
Subject: RE: computer account change password with Windows 2008 domain

Michael,

I don't know what is wrong, but I do know that our product works fine with Windows Server 2008 and 2003. We use our own Kerberos and GSS-API library (not MIT or Heimdal), and Cyrus SASL with OpenLDAP.

We have seen a similar problem where Active Directory on Windows Server 2003 has the LDAP Server signing policy set in the domain controllers group policy. This setting means that AD expects SSL/TLS to be used for signing, but when Kerberos/GSS/SASL/LDAP is used the signing is done using Kerberos keys instead. It seems that MS AD has a bug which effects use of SASL/LDAP bind when this policy setting is made. This is a discussed at http://technet2.microsoft.com/windowsserver/en/library/56044016-3123-4859-8fd9-c5a461a1c5c81033.mspx?mfr=true and I have included some output below which was shown when this policy setting is made. Not sure if this helps at all ? Perhaps your Win2k8 domain has a policy setting which is non-default and is causing your issue due to a similar bug ?

SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Strong(er) authentication required (8)
        additional info: 00002028: LdapErr: DSID-0C09018A, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, vece
Failed to connect to LDAP Server
Error occurred in netjoin while performing netjoin operations ( 0x00005102 20738 )
Cannot open connection to LDAP Server

Thanks,
Tim

-----Original Message-----
From: Michael Engemann [mailto:engemam at uni-muenster.de]
Sent: 07 January 2009 15:10
To: Tim Alsop; Michael Engemann; kerberos at mit.edu
Subject: AW: computer account change password with Windows 2008 domain

Hi Tim,

can you tell me than what am I doing wrong?
Even a simple ldapsearch that was functioning for Windows 2003 throws an error for 2008:


ldapsearch -Hldap://fqdn -b "" -s base -Omaxssf=0 -ZZ
SASL/GSSAPI authentication started
ldap_sasl_interactive_bind_s: Server is unwilling to perform (53)
        additional info: 00002029: LdapErr: DSID-0C09048A, comment: Cannot bind using sign/seal on a connection on which TLS or SSL is in effect, data 0, v1771

Thanks,

Michael


> -----Ursprüngliche Nachricht-----
> Von: Tim Alsop [mailto:Tim.Alsop at CyberSafe.com]
> Gesendet: Mittwoch, 7. Januar 2009 15:57
> An: Michael Engemann; kerberos at mit.edu
> Betreff: RE: computer account change password with Windows 2008 domain
>
> Hi,
>
> We are able to change/set passwords using Kerberos/GSS-API/SASL/LDAP
> when using Active Directory on Windows Server 2008.
>
> Thanks,
> Tim
>
> -----Original Message-----
> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
> Behalf Of Michael Engemann
> Sent: 07 January 2009 14:46
> To: kerberos at mit.edu
> Subject: computer account change password with Windows 2008 domain
>
> Hi,
>
> we are also experiencing the bug in Windows Server 2008 that was
> mentionend on this list in April 2008 by Russ Allberry:
>
> * 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.
>
> Are there probably any news about a fix or a known workaround?
>
> Thanks in advance,
>
> Michael
>
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos