I want to configure internet option via remote for windows 8. For example, I some pcs have two accounts, say admin,user. All pc connected via LAN with a server. How do I disable and enable internet from centralized server for only those users who have logged in via 'user' account? I asked for windows 8 machines.
The best way would be some kind of Centralized authentication and authorization.
Like the Microsoft ActiveDirectory, or An OpenLDAP Server.
Next you would need a proxy server where every program/user has tho authenticate to open up a new Connection to the outside world.
Another approach could be some kind of captive portal on your router (pfsense does this pretty easy and fast) for authentication.
This could also be paired with a centralized user management oder just local users.
Local Users (on every machine) have the problem that none of the settings and properties, such as passwords, could be synchronized and have to be set by hand on every machine.
Related
We have an application which is hosted on the on-premises Windows server (IIS) server
now I created a windows server on azure and building a web app for it.where the application needs to authenticate the user by windows server (DC) using kerbrose protocol but I couldn't find any documentation regarding this from Microsoft's side
Is the above query possible to be implemented in the azure web app?
No, it's not possible. Windows Authentication is something for on-premise deployments. For Azure Web Sites Azure Active Directory is clearly the best option. Sync from AD to Azure Active Directory is also quite easy to setup.
If you still want to absolutely use Windows Auth and host your website on Azure, you can create Windows VM and host your website there. You then need to join the VM to your AD. To this, both VMs must be in the same network. So if your VM is on-premise you will need to create an site-to-site VPN.
For more information, follow this SO which also discussed about this.
If your intention is to join the VM hosting the website to a domain then as others have mentioned, this isn't possible.
However, doing Kerberos authentication itself within an Azure website isn't particularly difficult, but it does require manual implementation. Windows natively handles all of this for you on domain joined machines and and IIS exposes that functionality. Since you can't domain join you have to manually do all that heavy lifting and request and validate the tickets yourself.
This involves creating a service account in Active Directory and keeping the account password in sync. Once you have that you need to indicate to the browser that it needs to negotiate auth, which is done with the WWW-Authenticate: negotiate header on a 401 response. The client, if configured to send tickets, will send a ticket in the Authorization: Negotiate YII... request header on a subsequent response. At this point you need to shove that negotiate header and that original service account password into something that can validate Kerberos tickets. Windows SSPI will do this for you, but it's a pain. I built a library that'll do this for you: Kerberos.NET. YMMV with what works best for you.
All of that said, it may be more beneficial to switch over to a more modern authentication mechanism like OAuth/OpenIDConnect/SAML.
There are several ways depending on if you have to allow access to users who are associated with a on-premise Active Directory or not.
You should have a look at this service: https://learn.microsoft.com/en-us/azure/active-directory-domain-services/
It will offer an Active Directory within Azure where you can domain join your VM to and then using Kerberos as authentication protocol (should work the same way like on prem).
The other option would be to create a new Active Directory within your Virtual Network (via 1 or 2 small Windows Server VMs where you create the AD).
The good thing if you are using Active Directory Domain Services would be that you could extend it to your on-prem Active Directory by synchronizing or federating your on-prem AD.
There are more informations regarding these scenarios here:
https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-hybrid-identity
For a Azure App Service - Web App you would connect it to your Azure Active Directory (AAD) and use the hybrid identity model to allow users who originate from an on-prem AD access to it:
https://learn.microsoft.com/en-us/azure/app-service/configure-authentication-provider-aad
Hope this helps a bit, it is a rather complicated topic you are digging into.
I have a server which runs Windows Server 2008 R2 Standard. I have admin rights and I can login through Remote Desktop Connection and access the server.
I wanted to create an account so that my office staff can access (restricted access) and only from office systems. I do not want access from any other location.
Is it possible ?
Thanks,
GR
There are several ways to lock down and secure the RDP services of a particular machine. As with most local services and GPO settings Windows is quite good at making it easy to tailor permissions based on user(s), computer(s) and by group(s).
First off I would personally add RDP permissions on a per user basis, rather than giving staff members one central login to use. There are several reasons for this, mostly down to ease of use and system security.
In the "System Properties" of the Windows Server, I assume you've ticked the box to allow a RDP connection to the server. - Just under that there's a checkbox you should tick in order to only allow connections with NLA (Network Level Authentication). Proceed to "Select Users" and choose the staff you wish to give RDP permissions too.
I'm going to assume that your RDP connection is working as you've stated that you're able to connect, we'll leave local RDP GPO settings and initial Windows Firewall configuration, please leave a comment if you'd like me to include it.
In the Windows Firewall for the server on the exceptions tab, edit the settings for Remote Desktop Connection. Click "Change Scope" and tick the box that says "My Nntwork (subnet) only".
This will only allow RDP connections from local machines within the servers subnet (office machines) and connections from the users you specified earlier on (Office staff).
As for the restricted access part, short of making a new local limited user on the server there's not much you can do to protect everything.
I hope this clears it up for you.
Corporate networks use AD mostly to authenticate users - in that desktop machines require signing in to a Windows domain - which is centrally managed/universal.
Now, if I had an iPad and I brought it into work, I wanted to be able to sign in to my AD so that if I type http://internal.link into my iPad browser, it would resolve just like it would on a Windows desktop machine inside that corporate network.
To do this, I presume that the iPad will discover the company wifi network, and I would like to sign in to that wifi using my corporate AD credentials. This leads me to my questions:
How can a wifi network tie itself to Active Directory, granting sessions only to properly authenticated AD users? Do I need to purchase particular wifi routers or do anything specific on the AD side?
If I was to sign in successfully somehow using my AD credentials, I will then have use of the company wifi - with accompanying access privileges to resolve internal-only URL's. What would it then take to get my iPad browser to enjoy features that are available to corporate IE users such as SSO (seamless sign on)? At worst, would an application at http://internal.link simply prompt me to sign in again with my AD credentials?
You're talking about two different technologies here:
AD is used to identify individual users on the network. It's for authentication and authorization.
DNS is used to resolve the hostnames of internal applications. I.E.: http://internal.link resolves to 10.0.0.5
With that said, your work probably has some sort of wireless authentication mechanism. I've never heard of them using AD for that, but I suppose it's possible. You need to get on the work's wifi. Once there, your IPad will either pick up it's DNS server settings from the network via DHCP, or you will have to manually configure them (most wifi networks use DHCP these days).
Assuming you are successful in getting on the Wi-Fi, and assuming that your DNS servers are established (via DHCP or otherwise), you should be able to hit any internal site from the iPad as long as the wifi network has access to those internal sites. There are various reasons that it wouldn't (i.e. firewalls, etc.). The internal site, if it's using AD/NTLM will ask you for credentials when you first visit it. You can usually just supply your AD username and password, and it will work fine.
I would ask your sys admin, he/she will tell you in a second. Even though it is set up with AD and that is rather common their are many possibilities for set up and it is most likely not set up over wireless.
I integrated a small http server in my software distribution, intended to allow access to my installed application from the customer's LAN.
Right now, the customer has to manually update the firewall's list of trusted applications. I want to either open a hole in the firewall at install-time, or to ensure that the firewall prompts the user to allow my web server as a trusted application, able to receive inbound traffic.
Any solution should work with the built-in Windows Firewall at minimum.
Suggestions?
I would start out by reading up on the following sections on MSDN. This should give you enough background to know what you need. In short you could be looking to talk to the INetFwMgr COM object.
XP
http://msdn.microsoft.com/en-us/library/windows/desktop/aa366453%28v=vs.85%29.aspx
Vista or later INetFwPolicy2
http://msdn.microsoft.com/en-us/library/windows/desktop/ff956124(v=vs.85).aspx
We have a team member in a different country, and are trying to figure out the most viable option to provide them with access to our Team Foundation Server for Visual Studio 2010.
You can check this http://msdn.microsoft.com/en-us/library/bb668967.aspx
If they are part of your corporate LAN/WAN, they should be able to get access just like a local user. If they are external, you have a couple choices:
VPN: You could give them VPN access into your network, then they could access like a local user.
Expose: You could expose TFS to the outside world by allowing the appropriate ports through your firewall.
You can also take a look at the TFS Proxy, but honestly I haven't done anything with that yet.
Open up port 8080 and route that port to the appropriate server. You can also setup to use HTTPS.
When the remote user is not on the same domain, he gets prompted for the credentials. The remote user can use the Windows Credential Cache (Stored Usernames and passwords for Windows XP).
Best solution is to enable TFS through a VPN for WAN users. Through port mapping you can enable TFS application tier access, but the Sharepoint (Documents) and Reports may not work properly. So, the best method is to enable VPS with SSL, and let internet users connect to your TFS just like internal users
Best of luck!