Why not just use kerberized logins?
--
Jared F. Nichols
Desktop Engineer, Client Services
Information Services Department
MIT Lincoln Laboratory
244 Wood Street
Lexington, Massachusetts 02420
781.981.5436

There is a script in the resource kit for this named mountNetworkShare.sh.

--

David Kucmierz
Mesquite ISD Technical Services
972.882.5506

Don't you have to know the keychain password to begin with? Since the
keychain is encrypted?

I've run this line on many end user machines to troubleshoot without being prompted for a pw. Only a allow/deny prompt comes up. I have no idea why, that was always my understanding as well.

~Joseph

I have got a feeling that maybe the user has their keychain open (ie
the pad lock is unlocked)? If you use the security binary you can dump
passwords to plain text, but for me to even access the keychain at root
I had to unlock it first

bash-3.2# security list-keychains "/Users/tlarkin/Library/Keychains/login.keychain" "/Library/Keychains/System.keychain" bash-3.2# security unlock-keychain ~/Library/Keychains/login.keychain

password to unlock /Users/tlarkin/Library/Keychains/login.keychain: bash-3.2#

and it prompted me for my password for my keychain. I am on 10.5.8

I believe your right I just tried it on one of the other sys admins machines and it failed wit the keypad locked.

So , using that as pw grabber was flawed logic from the beginning, it was too good to be true......

Someone else suggested I use kerberos tickets. So I Added <string>builtin:krb5store,privileged</string> to /etc/authorization so I'm no longer prompted for credentials when I connect manually with command + k

I'm trying to reverse engineer jamf's script to get a better understanding of exactly how it works before trying to implement it . Thanks for the help.

On 6/4/10 12:04 PM, "Thomas Larkin" <tlarki at kckps.org> wrote:

I have got a feeling that maybe the user has their keychain open (ie the pad lock is unlocked)? If you use the security binary you can dump passwords to plain text, but for me to even access the keychain at root I had to unlock it first

bash-3.2# security list-keychains

"/Users/tlarkin/Library/Keychains/login.keychain"

"/Library/Keychains/System.keychain"

bash-3.2# security unlock-keychain ~/Library/Keychains/login.keychain

password to unlock /Users/tlarkin/Library/Keychains/login.keychain:

bash-3.2#

and it prompted me for my password for my keychain. I am on 10.5.8

Your server shares need to be kerberized as well. I had a similar
problem with a testing software suite I needed students to map a
database share, and then launch the test afterward. What I did is have
my Novell guy create a generic testing account and gave it read/wirte
access to a single share on the network, then I just wrote an Apple
Script that mounted the share with that user:password in the script. I
know not the most secure way of doing things, but I had to. Since the
PC side was not fully kerberized and talking to the Mac side of things I
had to end up going this route.

The good news was that the database testing share had daily back ups,
and the script ran from the JSS so the students never saw the code or
anything else and it did not leave any user or password info in the
logs.

-tom

AD pushes out kerberos tickets to our clients and our solaris nas box has kerberos authentication enabled. So that's not a worry.

Our windows machines use kerberos to automount file shares using Group Policy so basically I need to replicate this on our macs.

Until now I never thought of using kerberos and jamf's script seems to rely on you having kerberos in your environment, so hopefully it works out.

On 6/4/10 12:33 PM, "Thomas Larkin" <tlarki at kckps.org> wrote:

Your server shares need to be kerberized as well. I had a similar problem with a testing software suite I needed students to map a database share, and then launch the test afterward. What I did is have my Novell guy create a generic testing account and gave it read/wirte access to a single share on the network, then I just wrote an Apple Script that mounted the share with that user:password in the script. I know not the most secure way of doing things, but I had to. Since the PC side was not fully kerberized and talking to the Mac side of things I had to end up going this route.

The good news was that the database testing share had daily back ups, and the script ran from the JSS so the students never saw the code or anything else and it did not leave any user or password info in the logs.

-tom

I'm sure Apple wouldn't allow this to happen. That would be a *huge*
On 6/4/10 9:46 AM, "HUGE | Joseph Simon" <jsimon at hugeinc.com> wrote:
security risk if any script could simply access a user's password without
his awareness.

The Kerberos idea is the best if your network is configured for the
service. To automount servers here I use this:

mkdir /Volumes/Some_Volume mount_afp "afp://;AUTH=Client%20Krb%20v2@server.domain.com/Some_Volume"
/Volumes/Some_Volume

You'd need to replace "server.domain.com" and "Some_Volume" with your
server information.

--

William Smith
Technical Analyst
Merrill Communications LLC
(651) 632-1492