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

Well... guess i'm going to have to force a sync from production. Only
way I can MAKE it fail...

I don't get why "write all properites" would let him get by. whether
its the NULL or not... all of the attributes that are in the failure
audit, he was explicit write permissions. No 'rogue" attributes show
up. So why could he write with "write all properties" to the same
attributes, that in other scenario, he has granular READ/WRITE applied
on 'User Objects' in advanced security properties.

When I uncheck samaccountname, the ones he needs to write to don't get
"unchecked". 'Write all properties' does get unchecked though. Via my
dssec.dat, I think I have damn near, if not, every attribute available
showing up.

I thought there would be something that "write all properties" was
giving him.... because that works. If I removed permissions to
something he needed to write to, it would be in the EVENT ID in the
failure audit with the others he can't write to.



Joe Richards [MVP] wrote:
Yeah this is where the trace would come in extremely handy, you will see
exactly what AD is saying and not have to rely on the error logging from
the developer...

He should not be seeing an access denied when trying to clear an
attribute that is already not set, he should be seeing something along
the lines of LDAP 0x10 - No such attribute with an extended error
message of 2076, problem 1001 (NO_ATTRIBUTE_OR_VAL) with the attribute
actually named. The DSID will vary based on the AD binaries on the DC.
This should all be in clear text in the trace unless he is using SSL or
some other form of protocol encryption and if he is, tell him to turn it
off so you can see the traffic or tell him to change the code to expose
the Extended Error information.

joe


--
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:
Its always been the same problem. A guy running code under an account
gets failure audits for writing to user attributes that he has both
read/write effective permissions. I can test the account, with now up
to 10 separate products and successfully write to the same attributes.

He did have "write all properties" for user objects and he claimed he
had no problems. I unchecked samaccountname and upn, removing that
account's write permissions. Now his code fails writing to OTHER
attributes as he is not even attempting to write those other 2.

Found out that he was deleting the AD user attribute before writing the
new value. Then saw a correllation between which attributes for which
users failed, and the fact that the attributes all had NULL values.

So I know he was trying to delete NULL values. When I tested, I don't
have a method to recreate what he's doing cause I really don't know, so
the only way I know how to script clearing a null works for me.

The problem is why he could delete a null value(if there were any) with
"write all properties" permissions for an attribute, but not be able to
delete it with just read/write permissions. Is there something about
the NULL value that requires extra juice ?

I don't know why the dummy wants to delete NOTHING. Its like me trying
to kick him in his A** and he had no A**. I don't want to waste
anymore time on him but I would like to know what the deal with that
is.

This is done in a testing domain that sort of mirrors production. I
know we didn't include all attributes in the sync to the testing
domain, so maybe he's just noticing that its failing more cause in
products those attributes have values so he doesn't try to delete NULLS
nearly as often.

The code makes a meta-directory authoritative. You make a change in
META, the attribute changes in AD. You make a change to the attribute
in AD, it changes it back to what the META has for the value.












Al Mulnick wrote:
Intriguing. I wonder what the original problem was?




"Joe_SMS" <jw_nagy@xxxxxxxxxxx> wrote in message
news:1154130352.549253.76210@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Okay.... something to add. We found out that his code was deleting the
attribute value before writing to it. Some attributes, we don't sync
to testing domain.

Failure audits were coming on attributes that had NULL values in AD.
Instead of running his code, we had him test the process with ldifde
and then we found out. When we were testing with the account he's
using, we were wrting values and deleting existing values with no
problem. Never bothered trying deleting NOTHING.

Question, he claims there wasn't a problem when "write all properties"
was set on the user objects. All that was done different permission
wise was that samaccountname and upn were "unchecked", which of course,
led to "write all properties" being unchecked.

Would something give him the ability to clear a NULL with "write all
properties". I almost believe him....but he's been wrong too many
times. Who deletes nothing ? Thats why I see nothing posted out there
I guess. Hope this narrows it...

Who's got that nugget ?




Joe, I appreciate your help immensely. I'm enterprise admin of 40,000
seats. My email address jnat514@xxxxxxxxxx I don't wanna get into a
thing about your products here with your MS MVP hat on.







Joe Richards [MVP] wrote:
There won't be a requirement to auth with say the UPN as any of the
credential mechanisms will result in the same token, however, if say for
instance the userid is specified with a blank password they would be
authenticated as anonymous.

--
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


Ace Fekay [MVP] wrote:
In news:eKrq18esGHA.4784@xxxxxxxxxxxxxxxxxxxx,
Joe Richards [MVP] <humorexpress@xxxxxxxxxxx> stated, which I commented
on
below:
Oh, to add on, using LDAP to update attributes works in a delegated
manner, I have seen it in hundreds of production forests and thousands
of test forests. If delegating specific attributes to a user and that
user can't write them then they

a. Aren't authenticating properly
b. Aren't using LDAP properly
c. Aren't just updating those attributes or are updating those
attibutes incorrectly.
Joe,

I was following this thread and initially I thought to ask how
authentication is written in the script. Now you mentioned A above, I
wonder
if it matters, especially in a multi-domain forest, or the fact that
LDAP
requires it, to authenticate using the UPN (username@xxxxxxxxxx)
instead of
an NTLM method (domain\user)? I think if it were the domain admin that
cached credentials are used, but any other account would require
specific
authentication? Am I off base?




.

Relevant Pages

  • Re: Send notification before PWDs expire
    ... that isn't as easy to do in script, ... Joe Kaplan-MS MVP Directory Services Programming ... take place in a production environment. ...
    (microsoft.public.windows.server.active_directory)
  • Re: CAS newbie
    ... The production web site is a two server ... If you are impersonating, then you will likely need to implement Kerberos ... Joe Kaplan-MS MVP Directory Services Programming ... code group to give full trust permissions to that dll. ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: Can Exmerge transfer permissions and calendars too?
    ... We're migrating from a third-party mailsystem to Exchange 2003. ... files and import them into the production Exchange server. ... What I'd like to know is if Exmerge can save mailbox permissions and ... will these permissions and linked appointments ...
    (microsoft.public.exchange.admin)
  • Re: A User wants DBO on a production db
    ... only statement permissions would fail if the user has the ... dbo) and data access is only through stored procedures, ... production DBA is to ensure the stability and integrity of the ... prod DBA is at odds with the ad-hoc changes to the production database. ...
    (microsoft.public.sqlserver.security)
  • Re: Cloning Production to Dev/Test/Train/Regression
    ... Not sure if I'm after a new feature or just some scripts, ... production database to say development, training, test etc. once we ... want the entire schema or user permissions across. ... This SAN clone option might be quicker then just adjust any views / ...
    (comp.databases.informix)