Greetings,

  I am developing a login script that writes the computer name to extensionattribute6 on the logged on users account and vica versa i.e. writes the username to extensionattribute6 of the computer account.

  This must run unelevated so I have given the write permission to SELF on this attribute and applied it to descendant user objects and the same permission to descendant computer objects.

  The user bit works fine. Any logged on user can update their own attribute. When writing to the computer account however, I get access denied. Why is this?

  It's as though when AD goes to verify SELF, it doesn't receive the Access Token of the current computer?

Thanks

David Z

>    I am developing a login script that writes the computer name   > attribute. When writing to the computer account however, I get access > denied. Why is this?   IF you are using a logon script, you are the user. If you grant SELF to a computer attribute, you should be the computer :)   Grant "Authenticated Users" for the computer attribute and it will work.   >    It's as though when AD goes to verify SELF, it doesn't receive the > Access Token of the current computer?   HOw should it? You are running as the user, not as the computer. To run as the computer, you need a startup script - but then, there's no logged on user...  

Thanks.

That's sort of what I thought but I didnt know in what situations the Access Token for the computer account is presented to a resource. It appears to only happen when no-one is logged on. So if a service or a startup script tries to access a resource, the Computers access token is presented but whenever a user is logged on, the users access token is presented. Would love a link that explains this theory. I always thought that both access tokens are presented because you are both a user and computer.

Auth users is a bit open but cant see the likelihood of someone maliciously wanting to stuff up my ext att6.

Thanks

David Z

Self refers to the object itself, so the object can modify itself. Maybe you should use "Authenticated Users" or "Everyone".

I know that. Its the conditions under which the Access token for a computer account is used to verify access to a resource is what I was interested in. I know a logged on user will always send their access token, primary or secondary.

That's sort of what I thought but I didn't know in what situations the Access Token for the computer account is presented to a resource. It appears to only happen when no-one is logged on. So if a service or a startup script tries to access a resource, the Computers access token is presented but whenever a user is logged on, the users access token is presented. Would love a link that explains this theory. I always thought that both access tokens are presented because you are both a user and computer.

It's all about context ;)

A domain member computer will startup, and authenticate to the domain, using it's own computer object/account/credentials/token.
The context of the threads on the machine are LocalSystem, and this effectively equates to computername$.
Startup scripts execute in this context, because startup scripts are for the computer, not for a user, and, no user is logged on at this point in time.

Once a user logs on, there is now the user context available for thread execution.