Auto fill user info

[#1]

Anyone have any tricks to have LDAP auto fill the username, real name, etc. into the computer record?

Right now, the only way to do this from what I see is click Edit on each record, then Location, type in the user's username from our LDAP, click Check Name, confirm, then save.

Any tips to do this faster?

[#2]

Hello,

Anyone have any tricks to have LDAP auto fill the username, real name, etc. into the computer record?

Check into the dscl command line tool, this should be able to quickly update
records however you will need to test thoroughly. `man dscl` for full
command list.

Philip

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have or believe you may have received this email in error please notify the sender immediately and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. The views or opinions presented in this email are solely those of the author or sender and do not necessarily represent those of Presbyterian Ladies' College. It is the responsibility of the recipient to check this email and any attachments for the presence of viruses. Presbyterian Ladies' College accepts no liability for any damage caused by any virus transmitted by this email.

[#3]

I should have mentioned I"m a junior level shell scripter so I may be writing more code than needed. Here is what I have working and I make no guarantees this will work in your env:

ShortName=dscl . -list /Users RealName | grep -v "_" | grep -v "admin" | grep -v "daemon" | grep -v "itcs" | grep -v "ituse" | grep -v "nobody" | grep -v "root" | awk '{ print $1 }';

FirstName=dscl . -list /Users RealName | grep -v "_" | grep -v "admin" | grep -v "daemon" | grep -v "itcs" | grep -v "ituse" | grep -v "nobody" | grep -v "root" | awk '{ print $2 }';

LastName=dscl . -list /Users RealName | grep -v "_" | grep -v "admin" | grep -v "daemon" | grep -v "itcs" | grep -v "ituse" | grep -v "nobody" | grep -v "root" | awk '{ print $3 }';

jamf recon -realname "$FirstName $LastName" -endUsername $ShortName

It's pulling the proper info and putting it into the JSS correctly.

If someone can shorten and sweeten this, much appreciated.

[jarednichols]

I don't see how dscl is going to populate this in the JSS' database. Am I
missing something?

It would be nice if a script on the server could re-run the LDAP lookup
occasionally. We have people frequently move offices or we have org changes
where they're now in a different department because a new one's been created
or collapsed. If the JSS could have a server-side action that rolls through
the username field and does a lookup against LDAP to update the information
every few months, that would be AWESOME.

It's a VERY manual process right now and automating that would be great
somehow... I smell feature request.

j

[#5]

There is a lot on the subject of auto update I'd be interested with and this is is one such example.

I'd also be interested in auto updating of gsx records, but that's a different story.

David Marcantonio
--------

[tlarkin]

Script out dscl records you want specifically and use recon to update that record. I think it can work that way.

[#7]

So I'm coming closer to filtering out the unwanted data. I have the following unix commands that pull out the data I want. The main user on the computer, filtering out IT admin accounts and other accounts on the box.

Initially, I use dscl to list all users on the box and output to a file: dscl . -list /Users RealName > users.txt

All users on the box are listed, plus non relevant accounts like www, svn, etc..

To filter out those accounts and all of our IT admin accounts, I did the following: grep -v "_" users.txt | grep -v "admin" | grep -v "daemon" | grep -v "itcs" | grep -v "nobody" | grep -v "root"

This output the real user of the computer: dma David Marcantonio

So now that I have the user's shortname and their real name, how do I get that into the JSS?

I'll wrap this up into a shell script, but I usually just loosely throw this in piece by piece.

If someone comes up with the output to the JSS, I would be forever grateful.

[#8]

OK, here is the final command to get the data I want and to pull out the needed data:

dscl . -list /Users RealName | grep -v "_" | grep -v "admin" | grep -v "daemon" | grep -v "itcs" | grep -v "ituse" | grep -v "nobody" | grep -v "root" | awk '{ print $2 }'

This will print the user's first name (eg. David)

Swap $2 with $3 and you will get their last name

So now to have the data submitted to the JSS.

[tlarkin]

Well, if you know that all actual users home folders live in /Users you can make this a lot easier on yourself. For exmaple, in my setup all local admin accounts used by IT have their home folders in /private/var/homes instead of /Users. That way I know that on the end user side all users home folders will populate in /Users.

So I can loop it like this for example:

for u in ls /Users | grep -v "Shared" ; do

Then every time I need a list of long names or short names I can call $u in further reference

examples:

dscl . read /Groups/admin GroupMembership | grep $u -c

Would give me a numerical output of either 1 or 0 if that user was in the admin group. Now, for you and what you want you could use that loop and do this:

dscl . read /Users/$u | awk '/RealName/ { print $2 }'

That would give you the real name of that user. Now to populate that you would use recon....example

sudo jamf recon -realname $variable

So if you set variables and a loop through /Users and then recon the machine with those variables of the data you want, you can write one script and make one policy do all of this.

Hope that makes sense, as I am on allergy medicine today.

-Tom

[#10]

So, wrapping this up in a shell script would be.........?

[#11]

You should just be able to toss in a:

sudo jamf recon ­endUsername

or

sudo jamf recon ­realname

Feed in the proper information afterward, of course. You can also fill in
any of the other fields the same way just pulling them out of dscl and
pushing them into the JSS with recon.

[tlarkin]

OK, please test it, I offer no warranties

#!/bin/bash

# need to populate JSS records with real names of users # This script assumes 2 things, 1 you are running the jamf binary and 2 all local users homes live in /Users

# Assuming 2 is correct, now lets loop through /Users

for u in `ls /Users | grep -v "Shared"` ; do

RealName=dscl . read /Users/$u | awk '/RealName/ { print $2 }'

jamf recon -realname $RealName

done

exit 0

That will recon the JSS with the real name of the user (the long name) to that particular machine in inventory.

[#13]

Hello,

I don't see how dscl is going to populate this in the JSS' database. Am I missing something?

Sorry, misread the original message to mean populating LDAP records (ie,
local -> Mac OS X Server) instead of LDAP -> JSS however everyone's got the
right idea to use jamf recon to link a computer -> User.

It's a VERY manual process right now and automating that would be great somehow... I smell feature request.

Sounds good, we usually update via jamf recon to set the username, realname,
email and asset details on the first boot process however we're probably
getting some entropy in the JSS database which could do with a bit of a
sanity check/clean every so often...

Philip

This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have or believe you may have received this email in error please notify the sender immediately and delete this email from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. The views or opinions presented in this email are solely those of the author or sender and do not necessarily represent those of Presbyterian Ladies' College. It is the responsibility of the recipient to check this email and any attachments for the presence of viruses. Presbyterian Ladies' College accepts no liability for any damage caused by any virus transmitted by this email.