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.
Related
I have mapped a domain evangelical.sg to use azure webapp custom domain. However it looks like the domain only redirect to https://efosingapore-wp.azurewebsites.net/
I've checked with domain support, they claim the problem is with azure settings somewhere.
I've set the "custom domain" settings on azure webapp correctly to evangelical.sg (although it still hasnt got SSL) yet the URL seems to still redirect.
Does anyone have an idea what went wrong, and how to fix this pls?
If your URL is redirecting to Tutorial ,
Try to redeploy the app by Deleting all the files, stopping the server, starting it again and then republish.
If you are facing any issues with TLS / SSL mapping , try to Map Custom Domain by following the below steps.
Map Custom Domain:
Go to Azure Portal
Select App Services- ->Select Your Azure App
Click on "+ Add Custom Domain"
Enter the domain and click on validate.
Add CNAME and TXT records in your DNS domain to verify domain ownership.
Click on "Add Custom Domain"
After adding the custom domain, the custom domain is still unsecure. You need to add the SSL certificate.
To add SSL certificate, please follow below procedure :
Go to TLS / SSL settings and click on "+ Add TLS / SSL Binding"
Select your custom domain and import the .pfx or public certificate for you domain and click Add.
Go to Custom Domains section and click on "Add binding".
Select the certificate of your domain and TLS/SSL type as SNI.
Click on "Add binding"
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.
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.
FOR DEVELOPMENT: I configured my site to run without SSL for my development box and it all works great.
Now I am moving this to our dev testing server so I can test it there.
I first ran it as a non ssl intranet site to confirm configuration and etc....
It works perfectly.
Now I am in the process of creating a cert for the site and plan to use self signed certs for developer testing.
I have read many post ( google search ) on the topic related to the error I am getting.
Basically, I am 110% sure I am not creating this cert correctly for the site to which I need to bind it to.
The error:
The remote certificate is invalid according to the validation procedure.
So I am trying to understand what they mean by answers like this:
When working with self-signed certificates: add them to the trusted root authorities & use the hostname instead of localhost. ]
So if your computer name is "mypc", the uri should be "https://mypc/..." instead of "https://localhost/...".
This is what is confusing to me...
For example , if computer name is: svr-d-web-003
So the uri: https: //svr-d-web-003/?????
Looking at the advanced settings Bindings could I extrapolate the uri as: https: //svr-d-web-003/webhost.oauth.xyz.org ?? This seems wrong to me...
Site settings and etc....
Used these steps to create the cert:
1. C:> certlm.msc
2. Right-click on Certificates, then click All Tasks/Request New Certificate
Click Next, Next
Click on link as shown under the template you need.
Select Common Name from drop down
Enter the machine name dns name (example: svr-v-wus-001), then click Add button
Click OK,
In the Requests Certificates window check the box for xyz, click Enroll
Look in the certificates store and it’ll be there – you may need to click Refresh button
Follow up In IIS – you’ll bind the certificate there to your site. Remember the name needs to match the url. (This might be my issue here...)
See attachment...
I finally got it to work.
When creating the cert I had to match the name of the cert (common name) to the site.
For example: the site is https://identService.oauth.xyz.org so the cert name needed to be identService.oauth.xyz.org.
Then it all worked. I was confusing the site name with the machine name. Doh...
My build agents are not starting after I change the properties credentials to the domain account from the network service. I done this because the network service account cannot write to my drop folder.
Each time I add the network service to the drop folder share, it appears then disappears.
http://msdn.microsoft.com/en-us/library/bb778394.aspx I followed this but some steps are different, i have xp and it doesn't show the share tab so i go through security tab
So I guess I'm asking two questions here;
Agents are not starting after changing credentials.
Network service not able to write to the drop folder.
Thanks in advance
Yes, Network Service won't have permissions to write to a drop location. That's pretty standard. You need to be using a domain account.
The TFS Build Service will need to run as a domain user so it can write to the drop location.
The domain account for the build agent will need to be in the TFS Project Collection group for build service accounts (internal to TFS). I can't remember what it's actually called but you need to be a collection administrator to update it.
The domain account will also need some login as batch/service permissions but that should be done automatically when you reconfigure the service. Do you use the TFS Admin console to reconfigure the agent or did you just set the credentials on the service? (You should use the TFS Admin console).