I can't connect to Azure ATP with a Domain Name with numbers as a domain

[ipcdollar1]

Azure ATP marks the domain field red when typing my domian name:

Example: child.01.contoso.com

How do I add credentials for my domain?

[#2]

Hi,

Is this an old domain from before Windows 2000???

Are all domains using the same format?

If not, as a workaround, are you able to add credentials from a different domain that does not have a dns part with all numbers, and also has full trust with this domain?

If yes, this should work around the issue until we can research it better.

[#3]

No, it's not a legacy domain and I don't see why that has something to do with it.

Is it not a just a problem with verification??? Numbers in DNS domain is allowed according to the RFC, right??

[#4]

Actually No,

See RFC 1035, section 2.3.1

https://tools.ietf.org/html/rfc1035

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less. 

 So you can use numbers in a dns name - yes, but any part in the dns name should *not* contain *just numbers*. 

so in the case of child.01.contoso.com

the .01. part is failing the validation.

if it was something like .a01. it would be fine.

[#5]

@Eli Ofek 

But you allow this for example:

nb.1we2.contoso.org

Why? 
If you are not compliant to RFC 1035, why not allow numeric only host/domain name?

[#6]

@ipcdollar1 

nb.1we2.contoso.org is compatible to the RFC.

Where do you see a DNS Part that is just numbers (which is not allowed) ?

.1we2. is not JUST numbers, it is both numbers and letters, which is OK.
In the previous example, you had  .01. which IS JUST numbers, which is not allowed.

Anyway, I raised an issue to product about it, to reconsider the RFC, as if effectively AD allows you to do that (which means AD does not conform to this RFC), we might need to change it to adhere to the same rules that AD use.

[#7]

@Eli Ofek 

The labels must follow the rules for ARPANET host names.  They must
start with a letter, end with a letter or digit, and have as interior
characters only letters, digits, and hyphen.  There are also some
restrictions on the length.  Labels must be 63 characters or less. 

 My example did not start with a letter.

[#8 · Accepted solution]

@ipcdollar1 , Taking back what I wrote before, you are correct. While the code declares it enforces the RFC, it's clearly a bug that it allowed first character as digit in the label.

I will add it to the internal ticket. Product will have to decide if they want to continue to stick to the RFC, in which case fix it to not allow, or change the rules to align with AD rules, which might make more sense here.

Thanks for the feedback!

[#9]

Hi All,
I have the same issue with an ADDS domain name that has underscore (is not DNS RFC compliant) but ADDS allowed it.
When do you think that this can be solved (alignment between MD4I sensor config and ADDS domain allowed naming syntax)?

[#10]

Hopefully sometime next week when Version 2.161 will be deployed.

[#11]

@Eli Ofek So now we are already on sensor version 2.173.14993 and the error still persists (throwing the error "Please enter a single label domain name (e.g., “Domain”)").

Do you have any more info on this issue?

[#12]

This sounds like a different issue.
I think a support case might work better here.

[#13]

Eventually contacted the MS Support (MD4I) and after a few email sessions, they concluded that it is a bug in the new defender portal (https://security.microsoft.com) since in the old MD4I portal this works as expected, and they will be validating this internally.