enable remote desktop access on specific machine via domain controller - windows-server-2008

we have a domain controller (W2008 RC2) and several computers as client machines. At the moment when we introduce a new user to the domain who has to have access to a subset of computers, the admin logs on to each of them and adds the user to the list of remote desktop users.
Is there a way to do this from the domain controller? (There has to be a way, because the way we do it sound a bit stupid, right?)
Best regards,
Sascha

Why you just dont add a remote_desktop group to every computer at once. Then put the user into that group if needed. Then you control the access of the computer-access-list at the user setting "Computer Logon at/when" options.

Related

Find Client PC name behind Remote Desktop connection

This is a bit general question.
I have a Windows application writted on VB (or whatever language) that has a login system. This app use computers registry to save and retrieve last login used, so the next time the user run the application it only needs to type his password. This works just fine.
Now one client wants to install my app in his server instead of clients computers and make all the pcs access the system via Remote desktop. No problem here.
My problem comes with the login system, because if i use the registry to save last login user, it will be only one (the server registry) so I always get last login user independet of wich pc access the system.
So my question is: How can I set a default user for each client PCs? I could use my database instead of the registry to save an retrieve last login user, but for then I'll need to know the PC name behind the remote desktop, and I don't know if thats even possible... Any ideas?
Thanks!
Note regardless duplicated post:
My question is different from the above mention. I don't need to get user name from terminal server. I just need a way to save and retrieve some data on the registry for each terminal service user or client PC.

IIS 6.0 on Windows Server 2003 setup for Integrated Windows Authentication but no direct access for users to the shared folders

I am attempting to set up an IIS 6.0 application running on Windows Server 2003 to use impersonation in order to avoid having to give users direct read/write access to the shared folders where the DB and web pages are stored. Can anyone provide me with details of how this can be set up to work in conjunction with Windows Integrated Authentication?
So far, I can tell that the web.config file (not sure whether it's the correct one) has the two lines mentioned on this thread (Impersonation in IIS 7.0) to allow impersonation and use the Windows logon method. However, users are still prompted for a logon and then told they are not authorized to view web pages. They can view pages if we turn anonymous logon "on", but then their user credentials aren't passed on to the site and therefore they can't access most of it.
I'm fairly inexperienced, so I'm a bit lost here. Thank you very much in advance for the help!
Thanks to intervention from Microsoft (definitely worth the flat fee they charge per incident), we were able to identify the problem. Instead of using the network path to identify the website location on the "Home Directory" tab of the IIS properties, we were using the local drive path. That was all that needed to be changed.
Once we switched to the network path and added a dedicated service account to "Connect As...", impersonation started working right away. Users pass their logged on credentials via integrated authentication (no logon required) and the service account takes care of executing their actions on the database file.
Access to the shared folder is limited to a brief list of administrators, and data access on the web application is limited based on user names.
If anyone is stuck with this and needs help, let me know!

VB.net create Active Directory account on another domain

I have two Active Directory forests on separate domains. Call them Domain1 and Domain2.
I want to be able to run this application from a computer in Domain1 and it will create an account in Domain2. I know this can be done in PowerShell by using new-pssession. Any help is appreciated.
-M
Excellent tutorial on all things .net -> AD.
http://www.codeproject.com/Articles/19689/Working-with-Active-Directory-in-VB-NET
You'll need to make sure that you have access to LDAP/ADSI from where ever you run the application though. Being on another domain isn't the issue, not being inside the current network where the AD server resides is, usually these things aren't internet facing due to it being a massive security concern.

Granular access control for MediaWiki with LDAP

My company has a MediaWiki setup which we are looking to make [partially] client accessible. Ideally each client would be able to see only their own page. Our wiki requires the user to be logged into view or edit, and we have the LDAP plugin (This one, specifically) so we can use our Active Directory credentials.
I see this question has come up before a few years ago, but I didn't see an question dealing with LDAP in particular. Can we manage a specific AD account if we give clients one on our domain for this purpose? Alternatively, is there a way to give clients a login directly into the wiki (sort of like logging locally into the computer, instead of the domain), that we could control the access rights of?
For reference: we are on MediaWiki version 1.19.1, PHP version 5.3.15, MySQL version 5.0.96-winx64, and the installation is running on Windows Server 2008 R2 x64 (IIS 7.5).
Thanks very much for the help!
You can use local accounts in addition to the LDAP accounts to log users in. You have to set $wgLDAPUseLocal to true in your LocalSettings.php. Basically, it adds another option to the domain drop down box on the login form that says "local". Users that want to log in with a local wiki account use that. I would also disable account creation on the wiki and create accounts manually for your clients.
Regardless of whether you use local accounts or AD accounts, for page-level access control, you would have to use one of these extensions. Extension:AccessControl seems to be a popular one.

Understanding IIS6 permissions, ACL, and identity--how can I restrict access?

When an ASP.NET application is running under IIS6.0 in Windows 2003 Server with impersonation, what user account is relevant for deciding file read/write/execute access privileges? I have two scenarios where I am trying to understand what access to grant/revoke. I thought the most relevant user is probably the identity specified in the Application Pool, but that doesn't seem to be the whole story.
The first issue concerns executing a local batch file via System.Diagnostics.Process.Start()--I can't do so when the AppPool is set to IWAM_WIN2K3WEB user, but it works fine if it is set to the Network Service identity. I of course made sure that the IWAM user has execute rights on the file.
The second involves writing to a file on the local hard drive--I'd like to be able to prevent doing so via the access control list via folder properties, but even when I set up all users in the folder as "read" (no users/groups with "write" at all), our ASP.NET still writes out the file no problem. How can it if it doesn't have write access?
Google search turns up bits and pieces but never the whole story.
what user account is relevant for [..] file read/write/execute access
As a rule: Always the user account the application/page runs under.
The IWAM account is pretty limited. I don't think it has permissions to start an external process. File access rights are irrelevant at this point.
If a user account (Network Service in your case) owns a file (i.e. has created it), it can do anything to this file, even if not explicitly allowed. Check who owns your file.
Process Monitor from Microsoft is a great tool to track down subtleties like this one.
A bit more searching reveals that the IWAM user isn't that well documented and we should stick with NETWORK SERVICE or a manually-supplied identity if we want to specify permissions for that user.