Windows Authentication : Which users are allowed - active-directory

Windows Authentication, Windows Server 2016 (or any version really)
When this is turned on in IIS10 this just authenticates against Active Directory, the user does not necessarily need to be a user on the server that IIS is sitting on right ?
Sorry for the dumb question

this just authenticates against Active Directory
Yes and no. It's called "Windows Authentication" and not "Active Directory Authentication" for a reason. It allows the website to authenticate any account that the server is capable of authenticating.
If the server is joined to a domain, then that can be an Active Directory account on the same domain or on any domain that domain trusts.
But it can also be a local account that only exists on the server itself - and that is true whether or not the server is joined to an AD domain.

Related

Unable to login using the Active Directory Credentials to an Amazon Linux server

I have provisioned a new Amazon Linux server in AWS environment and joined the server to the domain. I can see the Linux machine in the AD but cannot able to login using the AD credentials. However, I have tried to use the AD credentials but the following error has been encountered:
No Supported Authentication Methods Available (Server Sent: Public Key)
Could someone look at this and provide the resolution ?
In Amazon Linux, before you join the server to Active Directory make sure the password authentication attribute is set to true and AllowUsers string is added in /etc/ssh/sshd_config file.
Once added the required parameters, join the server to Active Directory and once joined, you can login directly with your AD credentials

Does IdentityServer 4 support Win auth with multiple Active Directories?

I've been reading the docs for Identity Server 4 (here) and it supports Windows Authentication and Active Directory.
Does it support multiple Active Directories?
Does it need to be configured somehow or Windows take care of it?
Thanks
That article is talking about running your application behind IIS. It's actually IIS performing the Windows Authentication, then passing the credentials to your application.
The answer to your question is "it depends". The server has to be able to authenticate your credentials. It can be from a different domain, but only if the domain your server is joined to trusts the domain the user account is on.
So if your server is joined to DOMAIN1, which is in an AD forest that has three domains: DOMAIN1, DOMAIN2, and DOMAIN3, then anyone with accounts on DOMAIN1, DOMAIN2, or DOMAIN3 can authenticate to your application.
Or if your server is joined to DOMAIN1, and DOMAIN1 has an explicit trust with DOMAIN4 (in a different AD forest), then users from DOMAIN4 can log in.

SSMS and Active Directory Authentication doesn't work with Azure SQL and non-Azure SQL

So we have Azure AD synced with our on-premise domain. We have an Azure SQL Server configured with the active directory admin. We also have a non Azure SQL server running on a virtual machine in Azure that is domain joined to this same domain. The following are the results of using the various authentication mechanisms offered by SQL Management Studio (SSMS). Can someone explain why the failures occur with the various options that should be supported?
Facts about environment:
Passthrough authentication is the sign-in method configured on AD Connect
Password hash sync is also enabled so password hashes are stored in Azure AD
Azure SQL is configured with Active Directory admin
Latest version of SSMS was downloaded when performing these test
On premise account was used to test all scenarios
Domain joined client connecting to Azure SQL from SSMS
Active Directory Password (PASS)
Active Directory Universal (PASS)
Windows Integrated (FAIL - not supported by Azure SQL)
Active Directory Integrated (FAIL – see error below)
Failure when client is standard domain joined client
Failure when client is Azure domain joined client
Domain joined client connecting to non-Azure SQL hosted on same domain
Active Directory Integrated (PASS)
Windows Integrated (PASS)
Active Directory Password (FAIL – Login failed for user ‘’)
Active Directory Universal (FAIL – Login failed for user ’’)
This issue may be related with the AD Syncing options. Verify in your environment that AD is not syncing passwords into the tenant. This prevents AD Integration Authentication and AD Password Authentication. The only authentication that works on these cases is AD Universal Authentication, as your test shows.
It looks to me that his is an ADAL problem (WSTrust) related to network configuration. Please create a support case and work with the support team to solve this problem

How i can authenticate in SQL SERVER 2008 with Active Directory User but without Windows Authentication

after reviewing a lot on the internet, I can not find a solution.
I hope you understand me, my English is not the best ...
Issue:
I want to authenticate against SQL Server with a valid user for the domain (active directory) which I get it from the login (username and password) of my application (old application).
This user, which is logged into my application, is a user validated by Active Directory (LDAP) and is a member of a Group that has logging permissions on the SQL Server ("Domain \ Group_name").
Attempts:
So the problem is that if I use windows authentication (it works fine) I would be using the windows user and not the application user (it is not always the same user). On the other hand, if I use SQL Server authentication I have to create and maintain the passwords of these users separately from the domain ...
Question:
How do I authenticate to SQL Server with a user logged in to my application. User who is a member of a Domain Group, which has logging permission in SQL Server but is not always the user windows logued on?
EXAMPLE:
Users: usr1 and usr2 both valid domain users
Usr1 is a member of the group that has access to SQL Server.
Usr2 is NOT a member of the SQL Server access group (can not log in).
I want to log in Windows with usr2 and in the application with usr1. Both with domain credentials.
Thanks in advance.
The only solution than i can find was the "runas", like SqlZim saw.
Thanks.

Active Directory Password Synchronization agent's Identity Manager User Password Expiry

Active Directory Password Synchronization agent is a tool supplied by IBM tivoli for Synchronizing the password with the enterprise applications that are integrated with Tivoli Identity Manager Application.This agent will be installed on all domain controllers in Infrastructure. Whenever a user or administrator changes the password this module captures the plain password and sends it to the tivoli identity manager platform. For this Active directory password Synchronization agent uses a ITIM(IBM tivoli identity manager) user and its credentials to propagate the password to ITIM. And the ITIM will have password rule that the password will expire in some number of days. The ITIM user of this AD agent also has to be changed when it got expired. When it got Expired when the user or administrator attempts to change the password can not change the password.
In test Systems we can just change the password of the user in ITIM and configure the AD Password Agent with the new password.
In production systems is there any way to propagate this change of password to all of the Active Directory domains ? How to handle this situation ?
If you are using a plateform before W2K8 R2.
On a server, can't you configure ITIM service to run as Local Service, Network Service, or Local System ?
Issues are, that these service accounts are simple to configure and use but are typically shared among multiple applications and services and cannot be managed on a domain level.
On W2K8 R2 and Windows 7
Two new types of service accounts are available in Windows Server 2008 R2 and Windows 7 : the managed service account and the virtual account.
The managed service account is designed to provide crucial applications such as SQL Server and IIS with the isolation of their own domain accounts, while eliminating the need for an administrator to manually administer the service principal name (SPN) and credentials for these accounts (password is changed automaticaly).
Virtual accounts in Windows Server 2008 R2 and Windows 7 are "managed local accounts" that can use a computer's credentials to access network resources.

Resources