I'm in the process of pulling a classic ASP app into Mvc2. I'll be deploying to an intranet and have been asked to enable support for Windows Authentication. The network I'll be deploying to has a few AD Domains and I'll only need to integrate with one in particular. Is it possible to use Windows Authentication and only allow authentication within a particular domain?
Along those same lines, it's not uncommon for a user to have an account in multiple domains (the account names themselves are typically different) - in the event a user logs in with an "unsupported" domain I'd like to kick them to a login form. Is this possible simply using Windows Auth or am I better off looking for an alternative?
Pro Tip:
Whatever you do don't implement Windows Authentication via IIS. Have a Forms Authentication page in your MVC app but use the LDAP authentication provider. This way you avoid the differences between how browsers implement Windows Authentication (only works well in IE and that's not a great reason).
The question "Is it possible to use Windows Authentication and only allow authentication within a particular domain?" has always has one and only one answer in my consulting experience: the answer is the permissions that you set for authenticated resources.
I've rarely found a deployment where there isn't some file, folder, server, COM+ object, SQL Role or database table that can't be "locked down" to only allow access by the subset of users you're targeting (e.g. "DOMAIN\Domain Users"):
Set permissions on the ASPX files (or the folder containing them, along with inheriting to the files) that are the "front door" (and optionally, all the others) so that they're only accessible to users in the "Domain Users" group for the allowed domain
restrict logon rights on the server that hosts the web site, so that only the Domain Users group have the appropriate rights - depending on the authentication provider used, this could be "allow logon locally" or "access this computer from the network"
set permissions at some layer of Component Services
restrict the SQL Server roles so that only "Domain Users" have the ability to read & execute the necessary database objects
Related
Assuming some web sites allow users to log in via Microsoft Login. Can we enforce that this users will only be able to use this setting only from within the Organization network in Intune? If yes, how? (Reference link)
Example: User is logging in to Bitbucket via Microsoft Login. He is unable to access Microsoft Login on his personal laptop. However, If he is using the Organization computer he should be able to access.
I believe this setting can be applied via IP Address? Or maybe there is another option.
I need to test the pass through authentication connection of a new website using PowerShell.
The code that I have just creates the website.
New-WebApplication -Name DLTItemAnalysis -Site 'Default Web Site' -PhysicalPath C:\inetpub\wwwroot\ApplicationFolder\ApplicationFolder -ApplicationPool ApplicationPool
Set-WebConfiguration "/system.applicationHost/sites/site[#name='Default Web Site' and #id='1']/application[#path='/Application']/VirtualDirectory[#path='/']" -Value #{userName=$ServUserName ;password= $ServUserPassword}
Is there a way to also test the user connection like the GUI has?
I am not really sure what you are asking for here. for as documented:
It is an authentication bridge and a new powerful way of cloud authentication while still keeping your passwords on-premise. It securely validates user passwords with on-premise Active Directory without the need of extra on-premise infrastructure like ADFS. Azure Active Directory (Azure AD) Pass-through Authentication allows your users to sign in to both on-premises and cloud-based applications using the same passwords. This feature provides your users with a better experience - one less password to remember and reduces IT helpdesk costs because your users are less likely to forget how to sign in. When users sign in using Azure AD, this feature validates users' passwords directly against your on-premises Active Directory.
When a user types in his user name and password on office 365 portal https://portal.office.com, office 365 service encrypt this using public key and puts it in a queue for validation, one of lightweight agent makes an outbound call from your network to retrieve the user name and password and decrypts the password using organization’s private key and validate it against local AD. Local AD sends back the resulting success or failure and it goes back to Azure portal via an agent and the user is authenticated.
So, this is nothing more than a standard Windows Kerberos auth request being redirected. So, you are only require testing for normal Windows auth.
As noted above, PTA is a communications channel, not an auth type, like basic, integrated, Kerberos, Kerberos(required), etc. For a target to validate a specific auth type, the target has to be configured for it. There is not PTA auth type as noted above that you can configure on a target.
Microsoft's PTA Video
User sign-in with Azure Active Directory Pass-through Authentication
What is Azure Active Directory Pass-through Authentication? Azure
Active Directory (Azure AD) Pass-through Authentication allows your
users to sign in to both on-premises and cloud-based applications
using the same passwords. This feature provides your users a better
experience - one less password to remember, and reduces IT helpdesk
costs because your users are less likely to forget how to sign in.
When users sign in using Azure AD, this feature validates users'
passwords directly against your on-premises Active Directory
Good day. Am working in an environment that requires a security approach for checking users account (users in the active directory are changing data in the SQL SERVER).
I want to link/tie the users of an active directory to the SQL server account login account.
Am working with Powershell, i type Get-ADUser -filter *, it gives me the list of all listed users. If i log into my SQL SERVER with "winnie", how do i link/tie the active directory user with the sql server user called ""winnie"
You should never give users access to a database by single Windows User or by SQL User. The reason for this is because of the security later on. It will be better to manage and audit a group compared to giving out single users. If you have to restore that database to a new system. It will provide better security between a Production system and a Test system.
The only user who should have access to a database is the SA account. The others should be controlled by Security Groups.
How do you do this:
In SQL Server Management Studio, go to Object Explorer > (your server) > Security > Logins and right-click New Login:
Then in the dialog box that pops up, pick the types of objects you want to see (Groups is disabled by default - check it!) and pick the location where you want to look for your objects (e.g. use Entire Directory) and then find your AD group.
Any member of that AD group can now login to SQL Server and use your database.
Add the Read or Write permissions to the Security Group of choice. Limiting security issues it the future.
Best Practice:
Create Security Groups
Security Group naming convention exmaples:
SG_DBNAME_READ
SG_DBNAME_WRITE
SG_DBSERVER_ADMIN
I am using the AspNetIdentity sample from the IdentityServer3 Samples file. When I start up the application the first page shows links for the Identity Server Welcome page and the Identity Manager User admin. When I click on the Identity manager admin link it automatically logs into the server and you can create, update etc any users, roles etc. How can this be modified to require a login? It seems obvious to me that this should not automatically log in and allow this access - am I missing something?
Identity Manager's default security is "Local Host" security. This means the caller/user is considered trusted if that caller is browsing from the same machine that is hosting Identity Manager. This is just the default, other security modes are available. Brock has a good video that explains the other modes.
My target site needs AD auth to browse and use the admin portal. All is fine there. This means syncing to this server via username and password authentication doesn't work. Does this mean i need to enable x.509 authentication?
If you mean using the Staging Module, the staging module's "Username and password" really is not linked to the actual CMS Users. You can put whatever Username and Password on the Destination server, and connect to it from the Source.
x.509 is also fine.
Tell me if you aren't talking about the Staging Module though.
You may need to do 1 of 2 things:
Enable mixed mode authentication. Yes the overall authentication doesn't need to use a physical cms_user user but since you have AD Authentication enabled, anytime another user or service tries to access a system page it may require them to log in.
Create a web.config location node in your /CMSPages/Staging/web.config file that excludes anyone or everyone to access a the SyncServer.asmx page within there.
Otherwise configure the x.509 certificate setup.