Non-forum related tech question

[TCinVA]

For those of you who know the Mac OS:

I have a Mac OS (Lion) workstation where the logged-in user has been set up with keychain access to a shared folder on a server. Let's call the server Data1, and the sharename is data.

Let's say I have another user who needs to access another share on Data1, sharename GRPH.

Does anyone know a good way of making the workstation pass on the second user's login information to access Data1\GRPH without having to first unmount the existing connection to Data1\data and then delete the keychain item?

The desired end state here is something a user can double-click on that will generate a login prompt to Data1 where they can enter their credentials and access the GRPH resource.

[tremiles]

To clarify:

User a needs \\data1\data

User b needs \\data1\grph

1 workstation, 2 users

Neither have access to opposite share?



Sent from my Nexus 4 using Tapatalk 4

[TCinVA]

To clarify:

User a needs \\data1\data

User b needs \\data1\grph

1 workstation, 2 users

Neither have access to opposite share?



User B sits down at a workstation that user A has already connected to Data1 on, and wishes to acces GRPH on Data1.

User A has no rights to \\data1\grph.

[Bigguy]

Sorry if I'm a little slow here. Are both users using the same login at the workstation?

[tremiles]

Sounds to me like user b sits at a workstation that user a is logged onto and without logging user a out, needs access to shared resource that user a doesn't have access to.

I'm a Windows guy, but it would be easy enough to setup a virtual workstation and remote desktop into it, and set a short disconnect/inactivity timeout so when user b is done, user a won't have access to user b's abandoned session.

The virtualization tools available to apple have similar functionality.

Sent from my Nexus 4 using Tapatalk 4

[Bigguy]

Unless user B needs access to some resource running on user A's session it seems like you could just set up an account on the workstation for user B with users B's keychain access to the required network resource. User B could simply switch to their account without logging user A off. Then log off from user B account when finished. Create an alias on the desktop to the shared folder on both accounts to easily move files.

[TCinVA]

Sorry if I'm a little slow here. Are both users using the same login at the workstation?

Correct. User A is a generic login that has to be already logged in on the workstation for other purposes.

User B is a real person who has to access some resources on a Windows server through SMB...only the generic user logon also has to access resources on that same server for different reasons, but the generic user doesn't have rights to the directory that User B is trying to access on the server. Everything I've tried so far authenticates one user or the other and then the credentials are stuck on the server for that session.

Creating a keychain entry for user B is not possible, as user B isn't really a single user...it can be any one of about twenty users who have to access a Windows resource with their own Active Directory account. None of whom are sufficiently tech savvy to be able to figure this one out for themselves.

So I'm looking for a way to force a new SMB connection to Data1 for User B that will require Use B to login.

Virtualization isn't an option because User B needs to work with the applications that are installed locally on the workstation and then save work product to \\data1\GRPH

[MDS]

You could run a vm on the windows host, give it access via the hypervisor to resources on the underlying windows machine, and have user b access the share on the vm. This is also a good test for your kludge meter - it should be pegged, overheated, and about to explode.

......... or you could just run Linux on server machines. (Duck!)

[tremiles]

Virtualization isn't an option because User B needs to work with the applications that are installed locally on the workstation and then save work product to \\data1\GRPH

Create an image of the workstation and use it for the VM?


Sent from my Nexus 7 using Tapatalk 4

[gringop]

In windows it would be
"net use /USER:domainname\username"
or
"net use /USER:computername\username"
or
"net use /USER:ipaddress\username"
then it would prompt for a password
Then
"net use \\computername\sharename"

You establish the credentials for the new user's SMB connection to the share then open the share.

For mapping a drive using the GUI in windows, you can specify to use a different username and passwd. For mounting a share on linux you specify the username, domain (or server) and passwd.

How to translate that to MAC SMB networking I don't know, and how to batch it all into a clickable Icon, I also don't know.

Gringop

[ToddG]

I can't believe none of you have the right answer.

Tim, just call the IT department. :cool:

[LittleLebowski]

For those of you who know the Mac OS:

I have a Mac OS (Lion) workstation where the logged-in user has been set up with keychain access to a shared folder on a server. Let's call the server Data1, and the sharename is data.

Let's say I have another user who needs to access another share on Data1, sharename GRPH.

Does anyone know a good way of making the workstation pass on the second user's login information to access Data1\GRPH without having to first unmount the existing connection to Data1\data and then delete the keychain item?

The desired end state here is something a user can double-click on that will generate a login prompt to Data1 where they can enter their credentials and access the GRPH resource.

I am not well versed with OS X shares in this configuration but have you not tried explicit permissions for each share and say, a quick bash script or Automator script to mount the share for the second user? Can the first user have access to the second user's share? If so, then can you not simply create a folder in the first user's share and then give read/write permissions to the second user?

This (http://superuser.com/questions/336665/how-to-automount-smb-shared-network-drives-in-mac-os-x-lion) should help.

Do the users browse the share via GUI or simply use an app to read and write from the share?

[TCinVA]

I am not well versed with OS X shares in this configuration but have you not tried explicit permissions for each share and say, a quick bash script or Automator script to mount the share for the second user?

The key problem there is the credentials. As far as I can tell, once the Mac OS logs on to a network server, it hangs on to the credentials used for the connection and then passes them through anytime a request is made to access the server, even if the credentials aren't stored in the keychain. So if User A accesses Data 1 at login (which is how the machines are set up) then User B (the real person) sits down and tries to access a resource on Data 1, User A's credentials are assumed and immediately passed through without challenging for a login.

If I could find a series of commands that would sever the connection to Data 1, flush whatever credentials were originally used for that connection, and then attempt to establish a new connection that would challenge for authentication the problem would be solved. I've written scripts for Windows that do exactly that...but I'm not familiar with how to accomplish the same within the Mac world.



Can the first user have access to the second user's share?


No, unfortunately...confidential data.



If so, then can you not simply create a folder in the first user's share and then give read/write permissions to the second user?


Also no, as there's a fairly complex and bureaucratically involved permissions setup on user B's folder structure. User B, remember, can be any one of a couple of dozen people. They each have their own folder with their own work product in it.

The other kicker is that I can't come up with an auto-mount script that passes through a username and password, because the usernames and passwords are all attached to real people who have real access to various systems. I can't know their password.

I know this all sounds like a bizarre setup, and it is. It's a situation created by about a dozen stakeholders who all answer to different chain of commands, and some of whom work for an entirely different organization. Throw in abject ignorance about what is the most versatile tool in the environment this workstation has to operate in (Macs don't play so hot in complicated corporate environments, IMO) and the end result is this mess.



Do the users browse the share via GUI or simply use an app to read and write from the share?

GUI access, primarily. Drag and drop files, etc.

[LittleLebowski]

The key problem there is the credentials. As far as I can tell, once the Mac OS logs on to a network server, it hangs on to the credentials used for the connection and then passes them through anytime a request is made to access the server, even if the credentials aren't stored in the keychain. So if User A accesses Data 1 at login (which is how the machines are set up) then User B (the real person) sits down and tries to access a resource on Data 1, User A's credentials are assumed and immediately passed through without challenging for a login.



No, unfortunately...confidential data.



Also no, as there's a fairly complex and bureaucratically involved permissions setup on user B's folder structure. User B, remember, can be any one of a couple of dozen people.

The other kicker is that I can't come up with an auto-mount script that passes through a username and password, because the usernames and passwords are all attached to real people who have real access to various systems. I can't know their password.

I know this all sounds like a bizarre setup, and it is. It's a situation created by about a dozen stakeholders who all answer to different chain of commands, and some of whom work for an entirely different organization. Throw in abject ignorance about what is the most versatile tool in the environment this workstation has to operate in (Macs don't play so hot in complicated corporate environments, IMO) and the end result is this mess.



GUI access, primarily. Drag and drop files, etc.

I'm probably missing something but are they using different credentials to log onto the host box (not the share server)?

[TCinVA]

I'm probably missing something but are they using different credentials to log onto the host box (not the share server)?

No. The workstation they are doing the work on has a generic auto-logged-in user.

[LittleLebowski]

No. The workstation they are doing the work on has a generic auto-logged-in user.

That complicates things. In what manner are the network shares presented to the workstation?

[TCinVA]

That complicates things. In what manner are the network shares presented to the workstation?

Visible in the Finder.

[LittleLebowski]

Visible in the Finder.

No, I mean AFS, CIFS/SMB, etc.

[TCinVA]

No, I mean AFS, CIFS/SMB, etc.

SMB connection with keychained credentials. Happens when User A auto-logs in.

[LittleLebowski]

SMB connection with keychained credentials. Happens when User A auto-logs in.

Sounds like you just need a separate username authenticated SMB share. Try this.


Open the Finder and click on the Network icon.
Click on workgroup name (maison in my example).
Click on server name (nas in my example).
Click on the Connect button.
Take note of share names and network server name on a piece of paper.
Open Automator.
Click on Finder under Library section.
Click and drag Get Specified Servers into rightmost screen section.
Click on the + sign in the Get Specified Servers window.
Type smb://server name/share name in the Address: field, and click Connect (smb://nas/mp3 in my example).
Repeat the previous step for the remaining shares you wish to automount.
Click and drag Connect to Servers under the Get Specified Servers section.
Click the Run button to test your workflow.
Save your workflow as a Workflow and Application.
Add your new Application to your System Accounts Login Items.

[JMS]

http://imageshack.us/a/img849/29/lx4h.jpg

[TCinVA]

TC, I unfortunately don't have time to test this but if the OS is remembering the credentials for the server without regard for the share name, how about creating a different server name for the second share?

I know you can't actually change the server and/or the organizations DNS, but you can add your fake host name to the desktop machines /etc/hosts file.

Tried that...but unfortunately if either the DNS name or IP is the same, then the OS recognizes it as the same server and the credential issue comes into play.

After doing more poking around on this, I've found out that it's Mac's blend of fuzzy UI functionality and the under-the-hood Unix that's causing the problem. In the terminal you're fully able to mount to multiple servers using different user ID's and you'll be able to browse them from the command line and see only the permissions that the user ID used for the mount had. In Finder, however, the first user to mount (and only the first user) has their permissions stick no matter what. If you direct the mount command properly then you can set it to access the other folder with alternate credentials, assuming you're sophisticated enough to make the command ask for an ID and password it can pass on.

That was doable, but not terribly user friendly.

So to get around all of this, I started looking into manipulating the keychain access. The workstation this is happening on has a software package called "DeepFreeze" on it which basically prevents any changes made to the machine to persist past a restart. Since I can count on the keychain entry to come back with a restart, I wrote a shell script that deletes the keychain item for User A and then tries to open a connection to the server...which prompts the user for authentication to the server.

That should get around the issue.

[LittleLebowski]

After doing more poking around on this, I've found out that it's Mac's blend of fuzzy UI functionality and the under-the-hood Unix that's causing the problem. In the terminal you're fully able to mount to multiple servers using different user ID's and you'll be able to browse them from the command line and see only the permissions that the user ID used for the mount had. In Finder, however, the first user to mount (and only the first user) has their permissions stick no matter what. If you direct the mount command properly then you can set it to access the other folder with alternate credentials, assuming you're sophisticated enough to make the command ask for an ID and password it can pass on.


With different shares, Automator could slap on a pretty icon to the under the hood UNIX functionality you speak of.