I have an NPS server which is configured to let company devices to connect to a bunch of Unifi AP's. Then I have a second NPS server which is configured to require Azure MFA when connecting to RDP sessions from outside the company network (2 defined RADIUS clients). Is there a way to consolidate the two servers? If you, any hint on how the setup with the policies can be done?
Thanks in advance
Na Wick
Looks like not, see this quote from one of the docs:
"Once you enable MFA for a RADIUS client using the NPS extension, all
authentications for this client are required to perform MFA. If you
want to enable MFA for some RADIUS clients but not others, you can
configure two NPS servers and install the extension on only one of
them."
Link: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-mfa-nps-extension
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 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.
I got a web DMZ server, that hosts an "Extranet" ASP.NET application. I want that users should authenticate to this application using the same user and password that they use on their Windows at work. (we are using Active Directory)
I want to know what the best way is -the most secure way - to connect from the DMZ web server to the Active Directory.
For now I saw two possibilities:
- RODC
- LDAP Over SSL (LDAPS)
Are there any other option you recommend? What other options should I consider? Any limitation, or potential problems with any of those solution?
It exist a Microsoft document talking about that :
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
You can also take inspiration from Microsoft consideration on installing an Exchange Front-end computer into a DMZ
Front-End and Back-End Server Topology Guide for Exchange Server 2003 and Exchange 2000 Server
Good morning,
I have found that many of my customers have MS Access already installed on their PCs. Although Access is very limited as a data store, I have found that it is great for deploying low-cost front-ends for entry level customers.
I want to start renting a VPS, so I can host customer databases using Microsoft SQL Server 2008, which they can access using a locally stored Access front-end. I do have a few questions though:
In order to access the remotely hosted databases, and use the security features, would the VPS need to be set up as a domain controller, using AD DS? If I am hosting multiple customer databases, this is not an option.
What I envisage is being able to set up a simple MS Access front end, to access a MS SQL Server database on my VPS. For security, I would want the database to use the Windows account on the client machine to authenticate, and also to provide basic data change tracking.
Is this possible? Or, will I need to set up a server for each client and have it configured as a domain controller, etc?
You can have many databases on the same server, so for each client you d not need to setup a separate domain controller. Only the connection strings will be different.
You can use SSL for establishing connection with the remote server to make the process more secure. You can also make a few web services to play with the data (CRUD operations), this would also make things more manageable.
take care :)
I am trying to set credentials (for running a job) using
cluscfg setcreds /scheduler:scheduler1 /user:domain2\user1 /password:pass
I get "The server has rejected the client credentials"
The client machine is in domain1.
Question:
1. Is this related to crossing the domain?
2. Is this related to some attribute on the account? That the account is not sufficiently
privileged to be able to run an HPC job?
Which domain is the scheduler in? If the scheduler is in domain2 and there's no trust relationship between domain1 and domain2 you may have credential problems. Can you use the Job Manager or Cluster Manager UI to look at scheduler1 from your client machine?
DOMAIN2\user1 needs to be configured as a cluster user (or administrator) on scheduler1. You can do that by manually adding DOMAIN2\user1 in the cluster configuration UI, or you can add some group which contains DOMAIN2\user1 (such as DOMAIN2\DOMAIN USERS).
Sorry for the late response; I don't check StackOverflow as often as I should :-\