Calling all Windows Experts :).
After a long time of testing, i was able to get ADFS4.0 working with a thirdparty application.
I can successfully navigate to thirdparty application, click login and get redirected to my adfs federation domain and be prompted for login, login without issues, then be logged into thirdparty site.
I went through various different articles regarding ADFS integrating with IWA and no matter what configurations I have made, I continue to get asked for a login which I do not want.
Brief walkthrough of my current setup. Note, they are not the real names but i thought i would make it easier naming them as to give you an idea as to how my settings are currently.
ADCS Server that just hosts a Cert. adcs.dctestdomain.local
Domain Controller that hosts a test domain dc.dctestdomain.local
ADFS server = adfs.dctestdomain.local. Federation server farm is adfs.publicdomain.com
I have followed the following:
https://help.hcltechsw.com/domino/11.0.1/admin/secu_creating_the_spn.html
host/adfs.publicdomain.com dctestdomain.local\SSOTest
spn = http/adfs.publicdomain.com dctestdomain.local\SSOTest
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-iwa
https://help.hcltechsw.com/domino/11.0.1/admin/secu_enabling_iwa_adfs30.html
`Set-ADFSProperties -WIASupportedUserAgents #("MSIE 6.0", "MSIE 7.0", "MSIE 8.0", "MSIE 9.0", "MSIE 10.0", "MSIE 11.0", "Trident/7.0", "MSIPC", "Windows Rights Management Client", "Mozilla/5.0")`
https://help.hcltechsw.com/domino/11.0.1/admin/secu_enabling_iwa_adfs30.html
Made the appropriate changes in the adfs server and the VM that is testing the adfs logins
Other things I have done:
nslookup -debug adfs.publicdomain.com shows that there is an A record and not a cname
(Get-AdfsProperties).WiaEvaluationMethod returns: WiaUserAgentDetection
`Get-ADObject -LDAPFilter "(|(ServicePrincipalName=http/adfs.publicdomain.com(servicePrincipalName=host/adfs.publicdomain.com )"`
Value shown is somewhere along these lines:
`CN=SSOTest,CN=Managed Service Accounts,DC=omitted,DC=omitted SSOTest msDS- GroupManagedServiceAccount`
`Set-AdfsProperties -ExtendedProtectionTokenCheck None`
Set the fqdn farm in the intranet zones, selected automatic logon with username and password(also tried intranet only) neither work
set Automatically detect intranet network
Set the public domain name in the trusted internet zones and set the same settings for testing purposes.
There is no load balancer
Everytime I get redirected from the 3rd Party site, I still have to log in to ADFS. Does anyone know what the problem may be? For security reasons, I did not provide real domains or account names but I think I have provided the best possible info. If you need more, please let me know. Any help would be greatly appreciated.
Related
Windows Server 2016, ADFS, Certification Authority
I tried to create duplicate web server template, but it says that it's not an accessible. see below snap.
Now, My client is not technical, he provide me an account with most of the access, account is not an administrator, but I can assign many access to my self using AD Administrative service.
My only question is which access DO I need to provide to this account for creating duplicate web server certificate template?
In a multi-domain environment, I have had the same issue, if I did not select a domain controller in the root domain, respectively in the domain that hosts the CA. In my case, another domain was chosen by the console, because my computer for remote administration is in another domain (child domain).
Try the following:
Open "Certificate Template Console"
Right-click "Certificate Templates" in the left pane
Click "Connect to another writable domain controller ..."
Change the domain
click "Ok"
Try to duplicate once again. :)
I know this is an old thread, but thought I might add a fix that could help others. The account you use to login to the CA server should have Enterprise admin rights and should also be a member of local IIS_IUSRS group. If you have verified both, just logout and login to the box again and you should be able to duplicate a template.
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.
So I have an MVC 2 App running on Windows Azure.
Everything works fine, but I want to create a subdomain where I can test some stuff that I need the actual server for, but I don't want anyone to see it. However, if I just put up like www.mywebsite.com/sandbox - anyone COULD technically access it, even though they'd have to know it's there, which I don't want.
Is there anyway I can setup something like that and password protect it or something easily? If so, I would use the same sort of thing for a private administrative URL where team members only could go in and check stuff (with a username/password that I maintain).
As far as I see it, you have two options available.
Create a staging deployment, and make the IIS web site respond to a specific DNS request (e.g. http://sandbox.mywebsite.nothere). Either change your DNS settings, or chane your local hosts file (e.g. in C:\Windows\System32\drivers\etc\hosts). This is security through obscurity, and while it's not effective, it's easy and perhaps a good start.
As suggested by Steve Morgan in a comment, implement authentication in your application. If you have an ASP.NET (MVC or not) application (I'm assuming MVC in my example), you can do with something like this:
Create a MembershipController
Create a Login action accepting username and password, implementation looking like this:
public virtual ActionResult Login(Qinoa.Web.Models.LoginData model)
{
if(model.Username == "myuser" && model.Password == "hardcodedPassword") {
FormsAuthentication.SetAuthCookie("myuser", model.RememberMe);
}
return RedirectToAction(MVC.Home.Index());
}
In your web.config file, set
<authentication mode="Forms">
<forms loginUrl="~/Membership/Login" timeout="2880" />
</authentication>
On all your test containers add an [Authorize] attribute. Your app is now (rudimentary) protected.
On a side note to #1: you can host multiple sites on one web role.
Configure your application using Windows Identity Foundation and the Access Control Service.
You then have a choice of Identity Providers that you can use to secure your application without managing your own users.
Even better, if you have Active Directory is to deploy ADFS 2.0 internally. The beauty of that is that even if someone reaches your application, they can't authenticate if they don't also have access to network on which your ADFS server runs.
I'm securing an Azure application this way and it works very well. I get transparent integrated authentication but it's highly secure.
You don't need to expose AD or ADFS outside your network to do this; there's no communication between Azure and ADFS, it's all done via the browser.
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