AD Profiler Lookup for Domain Joined Macs

[paul]

I have never seen domain joined Macs get the AD information set from the AD profiler.  Is there a technical reason for this?  The DHCP hostname is the computer name just like a Windows device.  If I take the hostname and do a lookup in ISE for hostname$ it works which is exactly what ISE does for Windows machines.   Is this supposed to work?

Thanks.

[howon]

It works the same way. Only caveat is that currently ISE profiling policy doesn't utilize any non-Windows attributes with AD probe. But, one could craft a condition and add it to existing Linux or macOS profiles.

[paul]

So you are saying the AD host exists flag should be set correctly?  If we aren't seeing that then this is a bug that we need to engage TAC on?

[howon · Accepted solution]

Yes, here is my example for macOS and Linux. It matches what is shown for the computer object in AD:

AD-Fetch-Host-Name    HOWON-MAC$
AD-Host-Exists    true
AD-Join-Point    AUTHC.NET
AD-Last-Fetch-Time    1539893492193
AD-OS-Version    10.14
AD-Operating-System    Mac OS X

AD-Fetch-Host-Name    ubuntu-desktop$
AD-Host-Exists    true
AD-Join-Point    AUTHC.NET
AD-Last-Fetch-Time    1539876555069

[Damien Miller]

For what it's worth Paul, I have a tac case open because domain joined windows machines aren't always being profiled as such. It's a 2.4 deployment and we did not see the same issue on 2.1.

Haven't been able to get one of these machines from the field for testing so the case hasn't progressed. It appears to be a low occurrence, but it's still happening. 

[paul]

Damian,



This could be a known issue I have posted on before and I have a bug being worked on right now. In version prior to 2.4 the AD profiler can do AD look-ups on DHCP hostname information or IP FQDN (DNS profiler) information. In 2.4, the FQDN lookup is broken. So if you aren't getting DHCP hostname data the AD profiler won't work in 2.4. Hopefully this will be fixed shortly.

[howon]

Yes, it only works with DHCP. Tracking with CSCve59881.

[paul · Accepted solution]

I am pretty sure FQDN AD lookups worked in 2.3. I used them all the time. The bug you referenced was an enhancement request in 2.2.



I got a new bug opened, CSCvm72309, to track the fact that this feature broke in 2.4.

[Damien Miller]

I'll look in to both. It's entirely possible that an ip helper could also be missing where we are seeing this.

One of the downsides to thousands of switches, config validation seems to suffer. 

[paul]

Yeah I am doing a ¼ million endpoint deployment and things like "IOS device sensor has issues on this version of code" and "we didn't think about this VLAN # so we didn't enabled DHCP snooping on it" all prevent DHCP info from being learned. I am not using an IP helper forwarding and am relying on device sensor for everything which can be "fun" at times.