Re: Oh.... I'm just wondering who's seen this stumper... RESOLVED !

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

Glad to see you got the low level details. I'm still not sure what the
answer was, but I wonder if you saw any controls loaded in the modify
messages that were different with the different permission sets,
specifically the permissive modify control (1.2.840.113556.1.4.1413). That
might explain the behavior difference, although it isn't clear why the
client would choose to use permissive modify in one case but not the other,
so if that is the problem, it really just pushes blame a little bit more.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services Programming"
http://www.directoryprogramming.net
--
"Joe_SMS" <jw_nagy@xxxxxxxxxxx> wrote in message
news:1154735227.717801.70500@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Okay with Joe Richards gracious and most appreciated help...

I have it figured out what he's doing that makes it fail with just the
granular attribute write permissions. From the request in the trace,
found he was doing a series of messy deletes then adds to the
attributes.

I duplicated his sequence with LDP and sure enough...INSUFFICIENT
RIGHTS and a failure audit.

In his sequence there were a couple of attributes that he had DELETES
for but no ADDS.

Then I gave his account WRITE ALL PROPERTIES for the test user. Ran
the LDP sequence again. This time it was NOT INSUFFICIENT RIGHTS, but
instead I go a NO SUCH ATTRIBUTE for each of those attributes that he
deletes but no adds...

Question STILL REMAINS. What part of "write all properties" let it
return NO SUCH ATTRIBUTE error instead of INSUFFICIENT RIGHTS when it
just has the granular attribute write permissions
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Oh, and if I remove those "***" deletes..... everything works
perfectly. :) Thanks Joe and Joe... just need that last answer....
and a KB article :)











Joe_SMS wrote:
Okay, I got the unencrypted capture. I see the "error message:
00002098: SecErr: DSID-03150a45, problem 4003 (INSUFF_ACCESS_RIGHTS),
data 0\n" But the request was deleting then adding multiple
attributes. I selected the packets and saved to a separate cap file.
Any Joe's out there ? Joe R. I'll just forward to your email address
if you have the time. THanks.






Joe Kaplan (MVP - ADSI) wrote:
Hopefully the encryption is configurable so you can get the actual LDAP
traffic. I don't think the mystery will be revealed until we see the
raw
LDAP ops. I'm actually all for encrypting the traffic as a normal
thing,
but not while troubleshooting.

And I agree with Al; modifying pwdLastSet is really fishy. You can
only set
that to 0 or -1. 0 forces password change at next logon and -1
basically
causes AD to set the value to "now", making it look like the user's
password
was just changed.

Joe K.

--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Joe_SMS" <jw_nagy@xxxxxxxxxxx> wrote in message
news:1154470040.690098.99720@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
It is SASL bind GSS-API Encrypted payload packets. The pricks. :) I
put in a request today for turning it off in the test domain for one
user, one test, one time. Just haven't heard the answer yet.
Strange,
they have now backed off and say that they can actually modify ALL of
the attributes one at a time, but..... theres always a but....

.... they said that during a full sync after a new user is created
when
it has update multiple attributes is when it fails. They think it
has
something to do with the fact that they delete the attributes before
they update them, don't ask me why cause I don't know why anyone
would
want to delete a NULL. Somehow, they think that when they had
'write
all properties', that gave them the right to delete a NULL valued
attribute. Thats their theory. They actuall took ldifde and did a
changetype modiy _ and when it failed with the operation error, they
said, SEE !!!

....I tried to tell them its not that you can't, its that you can't
with ldifde. I sent them vb code to pull my employeetype attribute,
display the value, then delete it, then display NULL, then do an
ads_property_clear on that. I can't wait for this to come down to
what
it actually is..... The directory will probably force them to
unencrypt
so that I can get the trace.

.....I'm thinkin' the full sync thing is doing something for which
they
have no clue, thus, can't tell us. But write all properties did
appear
to work which would explain that, what it doesn't explain is why the
only attributes listed in the failure audit were known attributes
that
we had given them permission to write to. What if they were setting
the password at the same time without permissions ? I dumped the
meta-data from a new created user. The full sync came 4 minutes
after
creation, added all those gal attributes, but then touched all 4
password attriubutes plus pwdlastset and
supplementalcredentials.....all within 2 seconds.. I mean, of the
enitre meta-dump of all attributes with values (60?) the ones the
sync
updated were either at 4:22:16 or 4:22:17. Awful quick to be doing
it
separately.

Thanks Joe






.

Quantcast