Mounting NAS volumes on AD session without authentication ?

[glpi-ios]

Hello,

I have a little problem that doesn't concern Jamf Pro but rather MacOS.
Maybe you can help me (I hope ...).

I use scripts to mount network volumes on our client computers.
Our computers are bound in Active Directory.

All volumes on SANs mount without problems (as long as the AD user permissions is good).

But with volumes on a NAS, the volumes doesn't mount for the good reason that it requires to put login / password while the AD session has the right permissions for volumes.

Do you know how to ensure that volumes coming from a NAS can mount without authentication on an AD session just like a SAN volume ?

Thank you for your help

[glpi-ios]

Sorry to up post (I don't like doing that), but please, if someone had a solution or an idea to share ....

Thank you and wish you a good day...

[glpi-ios]

Hi,

After multiple tests, I realize that when opening a new AD session for the first time, I can mount a NAS volume without it asking me authentication.

Once I close the session, it's over, every time I want to mount a NAS volume with this profile, it asks me to authenticate even if the AD profile has the necessary permissions.

I deleted the keychain, but it does not work.

So impossible to set up a script to mount the volumes automatically.

Very frustrating

Thanks

[ShaunRMiller83]

Can your NAS be setup to accept Kerberos tickets or for LDAP integration?

[glpi-ios]

@ShaunRMiller83 Thanks for your answer.

Our NAS is configured for AD/LDAP integration

[ryan_ball]

@glpi-ios What does the line of code look like that mounts the volume?

[glpi-ios]

@ryan.ball

Thank you for your answer
We have seen with our provider who asks us to mount the volumes with 'cifs://'.
But this is not the same as smb protocol?

Moreover, we mount the volumes with SMB but with 'cifs: //' it does not work at all....

Thanks

[ryan_ball]

@glpi-ios Do you use "osascript mount volume" or do you use the "mount" command?

[glpi-ios]

loggedInUser=$(stat -f%Su /dev/console)

umount -Af -t nfs,smbfs
rmdir /Volumes/*

sleep 5

Mount the drive

mount_script=`/usr/bin/osascript > /dev/null << EOT tell application "Finder"

activate

try mount volume "smb://xxx/xxx"
end try

end tell
EOT`

exit 0

But we have the same problem to mount volume manually, we have authentification window with the AD session has the right permissions for volumes.

[ryan_ball]

@glpi-ios Can you try this:

#!/bin/bash

protocol="smb"
loggedInUser=$(/usr/bin/python -c 'from SystemConfiguration import SCDynamicStoreCopyConsoleUser; import sys; username = (SCDynamicStoreCopyConsoleUser(None, None, None) or [None])[0]; username = [username,""][username in [u"loginwindow", None, u""]]; sys.stdout.write(username + "
");')
server="server_name_goes_here.contoso.com/share_name_goes_here"
fullPath="${protocol}://${loggedInUser}:@${server}"

umount -Af -t nfs,smbfs
rmdir /Volumes/*

sleep 5

# Mount the drive
/usr/bin/osascript -e "mount volume "$fullPath""

exit 0

[glpi-ios]

@ryan.ball

Thanks for your help.
But I have the same result. I need to authenticate :(

What seems odd is that when I open an AD profile for the first time on a computer, I can connect to a NAS volume without authenticating.
But as soon as I log off, every time I log in again, I need to authenticate to mount the same volume and all NAS volumes again.

I empty the Keychain but without success....

:(

[ryan_ball]

@glpi-ios This script is being run in a policy by Jamf, or in a LaunchAgent?

Can you attempt to locally run the script as the user, to see if you get any different behavior? Put the script on the desktop while logged into the machine and in terminal as the user execute the script.

[glpi-ios]

@ryan.ball I've tried locally as you explain and with policy. But I have same result.

I've tried with native MacOS 10.12, 10.13 and 10.14.
The only thing I do is binding in our AD then log in with AD accounts with permissions on our NAS volumes.

With SAN volumes, no problem, we don't have to authenticate if the account have good permissions.
Only with our NAS.