user-comment attribute - how to give user permission to update?

[Rob Dunn]

I am looking at implementing a script that would update an AD attribute with
the computername that the user is logged into. I would like to use the 'user-comment'
attribute. However, I'm not sure where to find the security setting to modify
this in my ADUC. Basically, I just need to give the user the ability to
update their own comment attribute.

Hopefully this makes sense...can anyone help?

Regards,
Rob

 

[Paul Bergson [MVP-DS]]

This sounds like a bad idea to me.


Take a look at LimitLogon and see if this would be of assistance to you.
http://www.microsoft.com/technet/technetmag/issues/2005/05/UtilitySpotlight/


--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Rob Dunn]

I'm not sure how this is supposed to help me. I'm not looking to limit logons,
I'm only trying to find out how to allow the users to have the ability to
update an attribute, which will actually be performed via a VBScript. Essentially,
the comment attribute would house the computername so we could find out easily
(perhaps not 100%) the last computer logged into under that account.

I think I got part of it figured out - I should be able to do this with the
delegate permissions feature, shouldn't I?

Rob

 

[Richard Mueller [MVP]]

There is a "comment" attribute of user objects, which does not appear in
ADUC. There is also a "description" attribute, which appears on the General
tab.

The problem with your idea is the replication traffic that will be
generated. A user can logon many times per day, but nothing is replicated
unless they change their password, which might be once in 30 days. The
lastLogon attribute is updated each time the user logs on, but it is not
replicated (a different value is saved on each DC). If it was, the increased
replication traffic would be significant. The "comment" attribute is
replicated. That's why this idea is not recommended.

An alternative is to have a logon script that logs user name, computer name,
and date/time to a shared log file. You could also have a similar logoff
script. I have a sample VBScript logon script that appends to a log linked
here:

http://www.rlmueller.net/Logon5.htm

 

[Rob Dunn]

Ah - ok, that makes sense...I can see how this may not be a good solution
for those that have large environments (like where I used to be...sadly),
but in our case here, we have about 137 users/computers which don't do a
lot of logging on/off (nor are they using Terminal Services/Citrix). So
would this still be a major concern?

We do have two remote sites that are replicating AD traffic, but I'm still
thinking that the infrequent log ins/outs may not be an issue for us.

My other alternative might be to query our Trend database (if I can figure
out how to get into it) for the info. At my last job, I used the EPolicy
Orchestrator database for this info, and that worked out very well.

 

[Joe Richards [MVP]]

Correct the solution doesn't scale.

Paul mentioned limitlogon because it has an audit mode where it will
just track where users are logging on. However it is probably a bit fat
for what you are doing and uses App Parts in AD which I am not
particularly fond of.

What would likely be an interesting solution for you would be to set up
an ADAM instance or two and then set up a CName alias that points at
those machines and then have the perms set up so that the user can
update an attribute on an object in the ADAM config set. This could be
done with some workstation class machines even. You don't have to worry
about your security and replication in AD then, it will all be in ADAM.



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

 

[Rob Dunn]

Just out of curiousity, how much traffic would be replicated per user if
this was implemented?

I do have it working, but I want to warn others if they ask me how I got
this solution going.

Regarding ADAM, I don't know anything about it, and I found a MS sites resources
referring to it; Active Directory Application Mode - guess I need to read
up on this!

By the way, here is the script I ended up with:

-----------

on error resume next
Dim strUserDN

Set WshShell = WScript.CreateObject("WScript.Shell")
Set WshSysEnv = WshShell.Environment("PROCESS")

'Get the logged in username
strUser = WshSysEnv("username")

'Get the current computer name
strComputer = wshShell.ExpandEnvironmentStrings("%Computername%")

' Get the NETBIOS Domain name
Set objSystemInfo = CreateObject("ADSystemInfo")
strDomain = objSystemInfo.DomainShortName

Function GetUserDN(byval strUserName,byval strDomain)
'http://www.wisesoft.co.uk/Scripts/display_script.aspx?id=118
' ^- original source of function...
' Use name translate to return the distinguished name
' of a user from the NT UserName (sAMAccountName)
' and the NETBIOS domain name.
Set objTrans = CreateObject("NameTranslate")
objTrans.Init 1, strDomain
objTrans.Set 3, strDomain & "\" & strUserName
strUserDN = objTrans.Get(1)
GetUserDN = strUserDN
End Function

'Put the DN into the variable strUserDN
strUserDN = GetUserDN(strUser,strDomain)

'Bind to the DN
Set objUser = GetObject ("LDAP://" & struserDN)

'Enter the computer name into the user's comment attribute
objUser.Put "comment", strComputer

'Set the info (save)
objUser.SetInfo
-------------------------

I had to go into the ADUC and delegate permissions to authenticated users,
and allow them to write to the read/write comments.

I realize this won't work efficiently for the larger environments, but for
the one on-site DC shops, this might be a good solution.

I'd like to also work out a solution with ADAM, but I need to learn about
it first!

Rob

 

[Richard Mueller [MVP]]

I think your script works, but as long as you use the ADSystemInfo object,
you may as well use it to retrieve the current user DN directly. For
example:
============
Option Explicit
Dim objNetwork, objSysInfo, objUser

Set objNetwork = CreateObject("Wscript.Network")
Set objSysInfo = CreateObject("ADSystemInfo")
Set objUser = GetObject("LDAP://" & objSysInfo.UserName)
objUser.Comment = objNetwork.ComputerName
objUser.SetInfo

 

[Ken Aldrich]

Hello,

The thing that gets me about all these replies... is that AD is a directory
service designed to hold information like this. It is designed to be
redundant and handle lots of replication. It makes me feel disheartened
that the recommended solution would entail brining up another database or
logging infrastructure to hold this information.

Regardless, I'm not sure anyone has actually answered your question yet.
Your question was basically, how do I delegate permissions in AD?
You could try to use the delegation wizard but I usually do not bother... as
it limits the choices available. Whether you want to use an existing
attribute for your user objects or simply want to add an attribute to your
schema and associate it with your user object class does not matter as far
as permissioning is concerned. You merely need know the attribute name and
the name of the Trustee. I would not worry about which attributes show up
in ADUC or not...you already seem aware of tools that can query AD for
attribute values.

Here is how I would go about delegating:
Open ADUC and browse to the OU/OU branch with your users in it. Right-click
on the OU and go to Properties.
Open Security Tab
Click Advanced
Click Add
For the Trustee, enter "self" and press OK
This opens another window
Open Properties tab
For the "Apply onto:" scroll all the way to the bottom and select "User
objects"
In the "Permissions:" window pane, find the attribute you are using for this
data and allow Read and Write.
Click OK through everything.

This should get you set up on permissions. We can also help you add a
custom attribute if you do not want to use an existing one... but it sounds
like you already have one picked out.

There is another approach that may help you. Since I do not know the
original problem you are trying to solve this may not apply. But, there is
a way to ask a Domain Controller what sessions it has open. You can also
ascertain what machines, and usernames those sessions are using. The
downside here is that to find a user, you may have to ask more than one
Domain Controller. However, it sounds like your organization is small
enough that you may only have a few Domain Controllers. If this route
sounds interesting you can contact my company using the information in my
signature. Fair warning, this approach would require you to buy our
software.... but it doesn't cost anything to look or try it out. We can
even do a webmeeting so that we can show you how it works in a live
environment.

 

[Joe Richards [MVP]]

I don't, in general, recommend putting any data in the global directory
that is only needed in limited locations. I also am not, and never was,
of the opinion that AD should be the every directory that MSFT initially
pushed back in 2000-2002 or so which they have obviously completely
backed off of now. It just wasn't what I considered to be a good idea.
In small to maybe medium shops, these things are fine. But as you scale
into the tens and especially hundreds of thousands of users (which is
where I do all of my work) or more what you do with the directory is
extremely critical to overall cust-sat of the directory experience. In
general, again, I try to keep the directory to as NOS a level as
possible. I see no reason, for instance to send Exchange data or other
app data for say Kokomo Indiana to say New Zealand when the Exchange
servers or app servers are in a DataCenter in California or London, etc.

While AD can keep up with a tremendous amount of churn (in fact I have
seen it smoke iPlanet for amount of churn AD could replicate over slow
lines versus what iPlanet could do over GByte) if there is no realistic
need to, why would you? It is silly from a cost standpoint as well as
possibly impacting the replication of important information like
password changes, account disables, or account unlocks. It isn't like if
a password needs to come through, the garbage make work data jumps out
of the way. The replication model doesn't work that way.

In addition, for this specific application, the idea is to maintain a
current listing of computer logon info which is not necessarily going to
be very current and is based entirely on your domain replication latency
which may or may not be understood and if understood may or may not be
known. In general while most companies understand the idea of
replication latency, few actually knew what their domain and forest
latencies were or even what the max and min theoretical latencies could be.

Finally, consider the amount of network traffic generated replicating a
12 character computer name around a domain of 20,30, 100 DCs versus just
writing it to a single DB somewhere.


--
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 Richards [MVP]]

The amount replicated would depend on how much you are changing. Say you
are just writing a 10-13 character userid you can then multiply that out
by how many users are involved and the avg # of times they logon
interactively in a day. Then start thinking about how many DCs this
change needs to go to. It is tougher to figure out what will happen
cross site as compression starts getting involved depending on the size
of the updates. All by itself, I wouldn't see this as too bad even in
large environments if you aren't worried about all of the wasted
bandwidth (you are replicating data you really don't need to be) but
consider that the bigger the environment the larger amount of churn
going on aside from this extra stuff. Every little bit adds up.

To get guidance on doing this, all you have to do is look at MSFT and
see that they don't replicate anything that changes for every
authentication. With K3 they added lastLogonTimeStamp which gets
replicated but it only gets updated by default, every week and a half to
two weeks (I have others posts you can google where I describe in detail
how that attribute is updated). Obviously, they have to handle any scale
so that is how they handle it. They could, in the example of having 2-3
DCs or even 10 in the same site is replicate all of that info but that
would be confusing (and more complex to write) to have the system
auto-tuning for all of that.

ADAM is very cool, it is Active Directory Lite. Basically AD without all
of the extra crap like Kerberos and DNS requirements and GPOs, etc.


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

 

[Brian Desmond [MVP]]

Rob-

Aside form all the technical how to stuff here, what is the purpose of doing
this? What problem are you trying to solve?

--
Thanks,
Brian Desmond
Windows Server MVP - Directory Services

www.briandesmond.com

 

[Rob Dunn]

Thank you for this, I'll update my script accordingly!

Thanks again for discussing this with me - I appreciate it...

Rob

 

[Rob Dunn]

I was trying to make an easy way for our help staff to determine what computer
a user was logged into (at least at last logon), just to help trim some time
off of our support calls. I realize that there are tools that help with
this such as psloggedin, and some scripts using the WINS database, but I
figured that AD would be a good place to put it, and also would allow us
to use it later on for inventory purposes...

I realize that if a user logs into multiple computers, this would skew the
numbers a bit, but for the most part it should be able to help us a bit.

I wrote a quickie blog entry about this topic here:
http://maximillianx.blogspot.com/2007/05/tip-network-admins-what-computer-is.html

If you have better info to add to this, let me know - last thing I'd want
to do is push misinformation!

 

[Brian Desmond [MVP]]

I see.

I don't work at a helpdesk and haven't, but when I have gotten stuck on end
user calls, I always just have them goto the properties of my
computer->computer name or start>run>cmd, set computername. Always works for
me. Time's money though so if this shaves 30 seconds off every helpdesk call
I imagine you might save something in the long run if you've got
beancounters accounting for all this.



--
Thanks,
Brian Desmond
Windows Server MVP - Directory Services

www.briandesmond.com