Mark Kinsey
asked on
Help Required for Mapping Drives from another Domain
Hi all,
I am currently in the process of putting a logon script together in order to map network drives for users. This should be easy, but the drive mappings will be connecting to storage on another domain - without any trust relationship between the domains.
There is a legitimate reason for the trust not being there, if it was this would be much easier.
Each user has their own logon script (%username%.bat), which has a list of drive mappings using the 'net use...' commands to map to the storage on the second domain. Within the second domain, they also have another AD account (exactly the same username format) with the correct permission to the storage.
My initial idea was to place a script called 'runas.bat' within the 'NETLOGON' area of the domain they're logging into, with a one-liner of runas /user:<secondDomain>\%user
The problem... the 'runas' script will not run against a UNC path, so the script also defaults to 'system32' and the %username%.bat scripts cannot be found.
I have seen suggestions of temporarily mapping a drive letter within the 'runas.bat' script, but this would get messy.
The domain they're currently logging into will soon go, they're in the process of migrating all users, business data, and applications across to the new domain. The data has been moved, so they need a very temporary solution to map to the new storage area from their soon to be decommissioned domain.
I realise for a long term drive mapping solution their are way better options, and the second domain already incorporates this.
What we are looking for is a very quick solution for a very short period, adding to the very old 'net use' method already in place.
Any ideas/suggestions would be greatly appreciated.
Cheers
I am currently in the process of putting a logon script together in order to map network drives for users. This should be easy, but the drive mappings will be connecting to storage on another domain - without any trust relationship between the domains.
There is a legitimate reason for the trust not being there, if it was this would be much easier.
Each user has their own logon script (%username%.bat), which has a list of drive mappings using the 'net use...' commands to map to the storage on the second domain. Within the second domain, they also have another AD account (exactly the same username format) with the correct permission to the storage.
My initial idea was to place a script called 'runas.bat' within the 'NETLOGON' area of the domain they're logging into, with a one-liner of runas /user:<secondDomain>\%user
The problem... the 'runas' script will not run against a UNC path, so the script also defaults to 'system32' and the %username%.bat scripts cannot be found.
I have seen suggestions of temporarily mapping a drive letter within the 'runas.bat' script, but this would get messy.
The domain they're currently logging into will soon go, they're in the process of migrating all users, business data, and applications across to the new domain. The data has been moved, so they need a very temporary solution to map to the new storage area from their soon to be decommissioned domain.
I realise for a long term drive mapping solution their are way better options, and the second domain already incorporates this.
What we are looking for is a very quick solution for a very short period, adding to the very old 'net use' method already in place.
Any ideas/suggestions would be greatly appreciated.
Cheers
There is a legitimate reason for the trust not being there, if it was this would be much easier.If you use a selective authentication on a trust it would be as if the trust does not exist and you can gradually set up permission required and on these computers set the Allow to authenticate permission
ASKER
Hi Karen,
The 'run as' script will not run against any UNC path. The script needs to call a batch scripts from within the NETLOGON area.
In regards to OS - the DC's are 2003. Within the new domain where we are migrating to, the DC's are 2008 R2. At the moment, due to other dependencies, all users must still log into the original domain but their drive mappings need to redirect to the new domain (as storage has been replicated across).
I hope that make sense.
The 'run as' script will not run against any UNC path. The script needs to call a batch scripts from within the NETLOGON area.
In regards to OS - the DC's are 2003. Within the new domain where we are migrating to, the DC's are 2008 R2. At the moment, due to other dependencies, all users must still log into the original domain but their drive mappings need to redirect to the new domain (as storage has been replicated across).
I hope that make sense.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Many Thanks Ben, in the end I chosen your alternative solution of creating additional accounts within the target domain - and added the credentials into the 'net use' scripts within the source domain.
Not secure at all, but without a trust in any direction I feel this is the best way forward. It is only temporary, so all should be good :-)
Not secure at all, but without a trust in any direction I feel this is the best way forward. It is only temporary, so all should be good :-)
Glad to help :)
Yup, less secure, but does beat having to ask them for the UN/PW every time, 6 one way half a dozen the other I suppose, which is why I left the choice among those three options up to you. Glad it helped you :)
Ben
Yup, less secure, but does beat having to ask them for the UN/PW every time, 6 one way half a dozen the other I suppose, which is why I left the choice among those three options up to you. Glad it helped you :)
Ben
Have you tried something like this: runas /user:<domain>\<user name> \\server1\share1\whatever.