Security

Hi,

 

This problem isn't caused by the wireless but I was hoping someone here might have an idea of what to check.

 

I have a laptop that is joined to AD and when it does machine authentication it is sending "host/COMPUTERNAME" not "host/COMPUTERNAME.domainname.com"

 

I looked around and as far as I can tell this is governed by a few registry keys under HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters

 

The keys are "NV Domain" and "Domain". These should be populated with the domain name.

In the case of the laptop these keys are properly populate.

 

When I check System > Computer name, domain...> Change settings > Computer Name tab

the "Full computer name:" shows only the computer name. Not the computer name + domain.

 

I have tried disjoining and rejoining the device. I have tried blanking the registery keys above, rebooting, and repopulating them. I have had no luck in getting the machine to it's full name.

 

Just curious if anyone has run into this and if there is anyway to "reset" the pc so that it appends the name properly. I have another idea for fixing this issue in the CPPM by just pulling the CN. But I want to try and fix the naming issue.

 

Anyone have any ideas on this one?

 

Thank you

You can try something like this:

The problem that I am facing that is that the machine isn't actually appending the domain name when the machine sends it's credentials.

 

So the machine is sending this: "host/COMPUTERNAME"

When it should send this: "host/COMPUTERNAME.domain.com"

 

I would like to try and figure out why the computer is sending in this format.

 

I was hoping someone might have seen this once before and know what needs to be changed on the PC side.

Apologize misread your issue

Bourne,

 

Is the machine failing authentication as a result?

 

@victorfabian

No problem at all!

I probably described it wrong.

And I know this isn't really a problem for this forum. But I was hoping someone might have seen this issue.

 

@cjoseph

 

Yes it is failing because the machine account isn't valid in the AD because I we are using the dNSHostName.

I know I can use something like CN to get around this problem.

 

But I am trying to figure out why this machine is behaving differently.

You probably tried this already:
Removed from the domain and added it again
Remove the wireless profile

@cappalli might know he's good with the windows stuff

I did try that yes, however I believe something might have gone wrong during the initial join of the machine.

 

I was reading this post and I started to look at the Service Principle Name attribute on the computer account in question. When I issues the command 'setspn -l <computername>' I noticed some discrencies when compared to a functioning computer.

 

Checking the attributes in the AD I noticed that the machine hadn't registered it's FQDN under the Service Principle Name. I tried manually adding the attributes, but this had no effect. So I am going to try completely removing the machines account from the AD and rejoin it and seeing if the values get populated properly.

 

No idea if this is the cause, but at this stage I am running out of ideas.

Tried a couple of additional things late Friday.

 

• I tried disjoining the machine and deleting it's AD account. I then manually created the machine with the proper dnshostname and SPN values. I then rejoined the machine. This did not work.
• I tried registering the machine with the DNS. Making sure that it's name properly registered with our DNS servers. This did not work.
• And as mentioned earlier I have tried playing with the registry.

I am out of ideas at this point. There must be something on the computer that is either misconfigured or missing. What that is though, at this point, I have no idea.

Reimage ?

Yeeaahh it might come to that :(

 

 

I was trying to avoid it because I am afraid that we might run into this again. I don't want to have to reimage each time we run into this.

 

The other solution would be to allow the machine to authenticate with it's CN name or dNSHostName. At least until I find a proper solution.

 

I have another post here. Might come up with something.

If I find anything I'll report back.

 

Thanks for all the suggestions guys!

True very valid point

Okay I think I found something else.

At first I didn't think this had anything to do with. But having done my own desktop computer I believe it does indeed play a role.

 

On the PC's that have the "Full computer name:" displayed properly they have an entry under for at least one of their network adapters.

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DNSRegisteredAdapters

On the computer I am having issues with this entry is missing completely.

I haven't been able to figure out exactly why this key is missing nor how to re-generate it.

 

I think though if I can figure this out it might lead me to correcting this issue.

 

This didn't pan out.

Sorry I have another question.

 

I am trying to get these machines to authenticate when they are sending the computer name in the following format "host/COMPUTERNAME".

 

When I looked into the AD auth source I noticed that they machines are in fact already authenticating using the "COMPUTERNAME" as indicated in the filter query below.

(&(sAMAccountName=%{Host:Name}$)(objectClass=computer))

 I am confused now as to why when these machines are unable to authenticate. It shouldn't really matter if it is sending "host/COMPUTERNAME" or "host/COMPUTERNAME.domain.com"

because it is looking at %{Host:Name}$ to authenticate.

 

When I look at the error in the Access Tracker I can see that for our AD source it is saying that the "user is not found", which to me is really strange.

 

I must be missing something obvious.

It might be because of this :

 

You may need to change it to this (I have not test this ):

 

 

Thanks for the reply.

 

I have checked the dNSHostName and ServicePrincipleName attributes and I have the following entries

dNSHostName:COMPUTERNAME.domain.com
ServicePrincipleName:HOST/COMPUTERNAME.domain.com
ServicePrincipleName:HOST/COMPUTERNAME

 With these entries shouldn't it work?

 

the dNSHostName is only being pulled as an attribute right? It doesn't have anything to do with the actually authentication of the computer account?

Hello again,

 

You guys are probably getting sick of hearing from me.

 

I finally figured out why the machine wasn't sending it's username properly.

 

I found this post which referenced a registry key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\System\DNSClient]

 There were two keys under here "NV PrimaryDnsSuffix" and "PrimaryDnsSuffix". Both of these keys were blank.

 

So I checked on computers that were working and discovered the the subkey DNSClient didn't even exists. So I deleted the whole key. Rebooted. And now the machine is sending it's username properly and it is displaying it correctly under "Full computer name"

Glad you figured it out , thanks for sharing the fix