Re: Oh.... I'm just wondering who' ..... SIMPLIFIED and need a simple answer

Tech-Archive recommends: Fix windows errors by optimizing your registry

FYI. I let the OP know already but I have submitted this as a bug to Microsoft. The ordering of the ops shouldn't have this impact.

The more standard way of doing an update like this would be a more efficient set of 2 REPLACE operations. In general you do better to make as small an LDAP update packet as possible so there is less to transfer across the network and less for the DC to process. So all attributes being updates should be handled with replace (or ADD if adding an additional value) and values that no longer should have a value at the end of the update should be deleted.



--
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:
...Down to this.

In LDP with WRITE permissions on JUST the attributes used.....

.....this will fail with insufficient rights and a failure audit.....

[delete]employeetype:
[delete]employeeid:
[add]employeetype:Contractor
[add]employeeid:123456

....but this works perfectly and returns a success audit.....

[delete]employeetype:
[add]employeetype:Contractor
[delete]employeeid:
[add]employeeid:123456

.....but they both work with "write all properties" or WRITE permission
on the user object....

There we go... there's the leg work.... anyone know the answer to
why.....

... the first one doesn't work ?

...does it have to be "write all properties" or WRITE permission on the
user object or is there something more granular ?

Thanks and God bless to whoever knows the answers to these. Its been a
haul. :)





Joe_SMS wrote:
Okay Joe I sent the capture and the latest..... its coming down to
this...

If you re-enact in LDP, you'll get the failure audit just like he
does... This is when that account has just "WRITE" permissions to the
specific ATTRIBUTES.

BUT..... if you just jump out and give the account "WRITE" permission
on the USER, then it succeeds as long as you use ldap_modify_ext_s and
the control.

Also if you notice the sequence, he has 'deletes' for C, PAGER, MOBILE
but he does not have any 'adds' for them. And he 'deletes'
msexchassistantname twice with only one 'add'.

If I simply remove those deletes he doesn't need, the failure audit I
sent ends up with only one attribute.... employeeid. It does have a
current value.

Just weird and I can't give him full WRITE on user
objects....




Joe Kaplan (MVP - ADSI) wrote:
Sure, go ahead and send me the capture too. You can use the email address
in the headers.

I'm starting to wonder if there is some sort of weird interaction between
permissive modify and the permissioning stuff that causes different errors
under different conditions. That's also probably a better question for Joe
R. or someone at MS than me though.

I do wonder why he's not just using replace instead of delete/add.
Delete/add is useful if you are doing deltas to multivalued attributes, but
if you just want to overwrite an attribute with a new value, replace seems
more straightforward to me.

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:1154785436.156815.201210@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
His request contains that control and critical=true.....

His request is formed in a manner such as....

delete a
delete b
delete c
delete d
add b
add c
add d
delete e
add e
delete f
delete g
add g

essentially if you duplicate the request with LDP and remove the
DELETES for which there are no corresponding ADDS, problem solved and
no failure audit. But I know what i'm gonna hear.

Why does "write all properties" on the user let him pull off this crap.
I can't give him that. If he CANT or says he cant or wont remove the
DELETES in the request for which he doesn't do an ADD, how do I more
granulary allow him to get by if I have to ? Or is it write all
properties or nothing ? I don't see sh*t in dssec.dat. So write all
properties isn't JUST giving WRITE to all attributes ?

Thanks Joe in advanced. Funny. Joe Kaplan, Joe Richards, nice to meet
you, i'm Joe Nagy. Surely a trifecta of Joes can put this to bed. :)
Joe K., let me know if you wanna see the capture.








Joe Kaplan (MVP - ADSI) wrote:
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