I was playing with Front Door and did set up a custom domain.
This domain is a Subdomain-delegations to my Azure subscription. Meaning for the domain myCompany.com I do not have access to the DNS settings, but the admin of myCompany set a delegation of sub.myCompany.com to a DNS zone in my Azure subscription. So I have a zone sub.myCompany.com in my account. Meaning I can only create A/Alias for sub.myCompany.com which I set to be an alias of my front-door.
This did work fine and I added the subdomain to my front-door and everything worked fine including using a SSL certificate from my KeyVault.
During playing around I tried using managed certificates and enabled that on the subdomain. And now the domain is stuck at "Domain validation" since a few days:
And I can't change this back because this results in the following error:
Failed to update the custom https configuration
Failed to update the custom https configuration for the frontend host '...'. Error: The requested operation cannot be executed on the entity in the current state.
How can I cancel that state to set it back to my KeyVault certificate?
I guess as this is not a CNAME-mapping it did fall back to e-mail verification and as the TLD is not under my control the mail got lost at the company managing the TLD. I do not have a direct contact with that company as I'm a subcontractor to the TLD's company and that company is also not managing the main domain on their own so it is not that easy to get ahold of whomever could have received that mail. And as the KeyVault certificate was working fine I just want to switch back to that...
I also had the problem that the domain validation was still not completed after many days.
I then opened a ticket in Azure and then the process was terminated in the backend. After that I was able to start the domain validation again and then it worked within 1 hour with the certificate
Related
I am new to DNS management. I bought a domain from Godaddy. I've added some records like i've pointed domain to my cloudways server. Added TXT for google console verification. At the same time I added TXT Records to authenticate my domain to Email SMTP Service Provider (Sendinblue.com). Within 10 Minutes my records were propagated, google verification was sucessfull and my domain was pointed to my server. But TXT's for sendinblue.com were not being authorized. Now its been more then 2 days still didn't authorized. I dont know if there is something i did wrong in configuration. May be there are multiple TXT's of same type. As I mentioned above my domain is pointed to my server and google console is verified. If these 2 records were propagated then sendinblue should also be authorized at the same time. But still i waited for 2 days and no success. May be some issue in configuration.
Domain configurations screenshot( https://imgur.com/a/nbPmKf4 )
After a bit of research i found a fix from a community. https://pk.godaddy.com/community/Managing-Domains/DNS-TXT-record-not-propagating/m-p/139411#M26840
So my 'enabling' HTTPS stage for my CDN endpoint has been stuck for 3+ days at 'enabling cdn' with the usual message of: a verification request will be sent to the email listed in your domain’s registration record (WHOIS registrant).
Now, I have the CNAME set as you can't even add it if it's not set to the right CDN endpoint. I have cancelled the process and restarted it after 2 days and now at the 2'nd attempt it's been hanging for 3 days.
The issue is the email for verification via the WHOIS will always go to something like protected-by-gdpr#gdpr-protected.com -- some type of placeholder domain as due to GDPR in Europe WHOIS data is no longer available.
This is not like 'WHOIS GUARD' that still leaves a way of getting contact, nor it is changeable, it is by default enforced across all domains as far as I can tell.
Now my questions is, what do I do to enable HTTPS on my custom domain if it doesn't care/look at the CNAME records?
According to this doc, If the CNAME record entry for your endpoint no longer exists or it contains the cdnverify subdomain,
DigiCert also sends a verification email to additional email
addresses. If the WHOIS registrant information is private, verify that
you can approve directly from one of the following addresses:
admin#<your-domain-name.com>
administrator#<your-domain-name.com>
webmaster#<your-domain-name.com>
hostmaster#<your-domain-name.com>
postmaster#<your-domain-name.com>
You should receive an email in a few minutes, similar to the following
example, asking you to approve the request. If you are using a spam
filter, add admin#digicert.com to its whitelist. If you don't receive
an email within 24 hours, contact Microsoft support.
You also could verify the above addresses. As far as I know, some similar domain ownership verifying question such as could not get verified from WHOIS registrant or your domain owner information is not enough exposed publicly so that domain ownership verifying has a failure.
To get fix these issue quickly, you can directly contact Microsoft support. They will confirm the domain information for you. See another similar thread.
I needed to add digicert to my CAA authorities in my domains DNS setting, because I already had a value present, it wouldn't let me issue certificates unless I added that there.
I followed Quickstart: Add a custom domain name to Azure Active Directory to verify my custom domain but still experiencing difficulties. I owe a domain (something like www.example.com with the only difference is mine is not 'example') purchased at GoDaddy.com.
If I try to verify that domain and specify its name (in AAD portal) as www.example.com then I can successfully complete the verification, but if I use the name example.com (without www) - I am seeing an error saying
Unable to verify domain name. Ensure you have added the record above
at the registrar 'MyDomainNameIsHere.COM', and try again in a little
while.
I employed nslookup to make sure the TXT record was added, I also followed the section Troubleshooting, non of those 3 cases apply to me:
waited for few hours
made sure with nslookup that the dns record is
correct and exists
there is no existing domain with that name
Why does it work if I prefix it with www and doesn't without it? Do I need to make some changes at GoDaddy?
I need that custom verified domain to add AAD users associated with their emails at my domain, for instance, User1#example.com; User2#example.com and so on. That doesn't work when I verify the www option complaining that example.com is not verified domain but doesn't complain if I try to create a user User1#www.example.com and I cannot do that because there is no corresponding email address.
I am trying to set SSL certification through Microsoft Azure.
I purchased SSL certification and basically followed the steps here: https://learn.microsoft.com/en-us/azure/app-service-web/web-sites-purchase-ssl-web-site
However, I'm stuck in the Verify stage for quite a few hours.
I'm trying to verify using my DNS zone file. According to the instructions I get in Azure's wizard:
I added the following Zone record.
But when I hit 'refresh' my website does not verify. Can anyone see the problem?
According to this atilce, you will find you should add txt record as below:
DNS TXT Record Verification:
Using your DNS manager, Create a TXT record on the # subdomain with value equal to the Domain Verification Token.
Click “Refresh” to update the Certificate status after verification is completed.
So I suggest you could add record as below:
GoDaddy manage DNS as below:
Or you could add txt record as below:
#.<domain> with value <verification-token>
After 5-10 minutes, you could refresh the domain verification, it will work well.
We have Single Sign-on working for a test application in Azure, using Azure Active Directory and the on-premise server running DirSync to synchronise the user details.
I have added a Custom Domain and verified it, by adding TXT records to the DNS entries at my registrar's website. In order to do this, I followed advice (from stackoverflow questions) that I needed to untick the option that said "I plan to configure this domain for single sign-on with my local Active Directory", in order to gain access to the additional information that allows me to prove ownership of the domain.
As a result, the domain has been verified and Azure recognises this, allowing me to see the domain as being 'verified', but the Single Sign-On value for this custom domain is set to 'Not Planned'.
The problem is now, I want to be able to re-tick that check box, and enable this domain to be used with the single sign-on, as I don't want to have to tell my users to use their log-in email addresses as 'username#something.onmicrosoft.com' as they'll never get it and will pester me to change it.
So, my question is: Is there a way to re-tick this box, and change the status of this field away from that of 'Not Planned', and (hopefully) to allow my users to sign in using their username#domain.com instead?
I have tried to remove the domain and re-add it, but Azure stops me from deleting it, as it's probably already well utilised in the rest of the processes. Also, I have no ability (or at least that's how it seems!) to go back into this custom domain within Azure and modify it.
UPDATE: I have tried to Deactivate the Directory Integration directory sync - this allows me to adjust the sync'd user's email addresses, but they're reverted back to .onmicrosoft.com once the sync is Activated again.
UPDATE 2: I have tried to install PowerShell to remotely administer the custom domain to becoming active, but I just cannot connect, despite several hours of trying.
If you added (and verified) a domain without ticking the checkbox, your domain is considered "standard", or "managed". You can convert this domain to a "federated" domain with the Convert-MsolDomainToFederated cmdlet from the Azure Active Directory PowerShell module:
Convert-MsolDomainToFederated -DomainName "contoso.com"
Tip for next time: After you add the domain with the single sign-on tick, you can run the following to get the DNS records to verify the domain:
Get-MsolDomainVerificationDns -DomainName "contoso.com"