The application does indeed use LDAP. It _appears_ that the issue is the API ldap_simple_bind_s.
MSDN documentation says that nothing Microsoft supplies uses that API in Windows XP. One may reasonably extrapolate that to include Windows 2003. But I can't find anything that states that the API was deprecated between Windows 2000 and Windows 2003. Or between windows 2000 sp3 to sp4 (although there are minor hints). I've turned on auditing (hours ago) and almost nothing shows -- either success or failure. I don't know what it takes to trigger an audit event, but a simple ldap query doesn't seem to do it, or a failed ldap_simple_bind_s. I've suggested (requested) a change to ldap_bind_s but is there documentation somewhere that I am missing that says ldap_simple_bind_s will no longer work properly? Thanks for your hint, it got me headed down the proper path. Michael -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Tuesday, January 27, 2004 2:48 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Change in A/D security between 2k and 2k3 yes, there are various security changes in Win2k3, incl. different default ACLs on various objects. But as you've created a special account for the app, you shouldn't need to enable anonymous LDAP operations on your Win2k3 DCs => however, the app needs to leverage the credentials correctly to bind to the LDAP server (the DC). The real question is: what does the app really do? Do they even perform LDAP queries or do they use some NT4 APIs to read data from AD (I've seen this too many times, although the vendor swore they were not). You need to understand what the App does, before you can apply the correct security - as you've mentioned, often you don't require to change anything if all the app requires is to list user accounts or groups etc. A good place to start to help figure out this issue is AUDITING: go to your Default DC policy and enable "Audit directory service access" for success and failure (preferrably in a lab, ofcourse). Then start up your mis-behaving Application, wait for it to fail and take some time to wade through the security Eventlogs => often you can find a particular AD object (incl. the DN) which an app tries to access when it fails. This gives you new options to check out the permissions really required by the app (or to tell the vendor how to correct a problem in their application). /Guido -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael B. Smith Sent: Dienstag, 27. Januar 2004 16:51 To: [EMAIL PROTECTED] Subject: [ActiveDir] Change in A/D security between 2k and 2k3 I run an application (ModusGate by Vircom, if anyone cares) that requires "read access" (their phrasing) to A/D for LDAP queries. In Windows 2000, this was easily done in ADU&C -- create a user, View->Advanced, properties on the domain, Security tab, add the user and grant "READ". I can do exactly the same thing in Windows 2003, but it doesn't work anymore (and, in fact, the way I read the permissions I shouldn't even need to do it with the change in the default permissions). The ONLY account that works is the Administrator account. I can create an account, add it to domain admins, enterprise admins, blah blah blah -- so it looks just like Administrator and it still fails. So, I presumed it was User Rights -- so I add this account and give it the same everything there too (in Domain Controller Policy and Domain Policy). Still no joy. Applied change suggested in KB 326690. Still no joy. Vircom is baffled as well, they say. Any hints or suggestions for me? Thanks. .+-wÈi0g-í+YbémPiæ0æ-í+bíÚf.+-j!ç 0j!åoræyØIíV+v* List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ â²Ø~ˆm¶Ÿÿà rØyØ¢¸?™¨¥–+-†ÙŠËEm¶Ÿÿà rØyØ¢¸?–+-}ª¡¶bâ²Ör¯zm§ÿðà šŠV«r¯yÊ&ý§-Š÷4™¨¥iËb½çb®Šà
