Re: Oh.... I'm just wondering who's seen this stumper...
- From: "Joe_SMS" <jw_nagy@xxxxxxxxxxx>
- Date: 27 Jul 2006 15:52:36 -0700
Thanks...this is getting interesting. I was hoping someone I
recognized responded. I use adfind>admod religiously. Once I
memorized that extended help page for adfind. :)
So you're saying netmon capture while the update fails right ? Any
help with what I should filter for so i'd recognize the extended error
info and DSID ? I'd appreciate any insight. Doing this in the test
domain. Testing a provisioning tool that modifies AD "gal" attributes
after they are modified in a db2 database, or overwrites changes made
in AD that don't match the database. It seems when I delete the
attributes from AD, the tool can update the values within 3 seconds no
problem. But, when they test on their end modifying data in the
database which then tries to update AD, it fails on the same attributes
with the same account. One for the ages..
Thanks again.
Joe Richards [MVP] wrote:
Get a network trace of the update, the info needed to troubleshoot the
problem should be in the extended error info that is returned. Post the
extended error including the DSID.
--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net
---O'Reilly Active Directory Third Edition now available---
http://www.joeware.net/win/ad3e.htm
Joe_SMS wrote:
Some developer running some code to update user attributes via LDAP in
AD (win2k3), He needed rights to 25 attributes, none mandatory. While
testing with "write all properties" permissions on the user objects, he
can write to those 25 everytime he claims and no failure audits back
that up.
But, when I cut the perms back to limit him to just those 25, his code
fails and he has no error checking (don't ask), and all he gets is
"insufficient rights". When I check the security logs, there is a
failure audit 566 for write properties on the user for the attributes
that he actually has permissions to write to.
I can take LDP and using the same account as he, update all 25 at the
same time without a hitch and get a success audit for write properties
with the same account on the same DC FOR THE SAME ATTRIBUTES HES
GETTING THE FAILURE AUDITS FOR. His code syncs attributes from an
authoritative database.
If someone could tell me how this is even possible, that would help.
At no time when I see his failure audits are there any extra attributes
that he's trying to write to outside the 25. He does of course, have
read access to all attributes.
Any clue at all would be much help. How can you get a failure audit
for writing to an attribute with an account that has write permissions
to that attribute ? Then when I use the same account, I successfully
write to the same attribute.
I'm 19 years in IT... so i've already checked 99% of what you're
thinking. :) who got that 1% ?
Thx in advance.
.
- Follow-Ups:
- Re: Oh.... I'm just wondering who's seen this stumper...
- From: Joe Richards [MVP]
- Re: Oh.... I'm just wondering who's seen this stumper...
- From: Joe Richards [MVP]
- Re: Oh.... I'm just wondering who's seen this stumper...
- References:
- Oh.... I'm just wondering who's seen this stumper...
- From: Joe_SMS
- Re: Oh.... I'm just wondering who's seen this stumper...
- From: Joe Richards [MVP]
- Oh.... I'm just wondering who's seen this stumper...
- Prev by Date: Re: Published application - what rights does the user need
- Next by Date: Re: User password change causes all cached profile passwords to be bla
- Previous by thread: Re: Oh.... I'm just wondering who's seen this stumper...
- Next by thread: Re: Oh.... I'm just wondering who's seen this stumper...
- Index(es):
Relevant Pages
|
