LDAP query for machine account?

If anyone knows how to do this properly, please let me know, but for now I am trying something else as I can't seem to get it to work.

Instead, I am querying the client registry for "HKEY_CURRENT_USER\Software\Policies\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\our_internal_domain" as this registry key does not exist if the machine is not in the domain. I guess it could theoretically be faked but it is the best check I have come up with so far to validate that the machine is in the domain and has had the Users GPO applied at least once to get the IE Zone settings pushed to it.

A few things to consider:

1. An LDAP query is generally an inward facing mechanism - to query a server for some information about a client.

    

2. The target of the LDAP query would have to be running an LDAP server (or Active Directory services), which a client would not normally be doing.

    

3. As you've discovered, the client side registry check does not return any values other than a "presence of" true/false (is present or equals).

    

Depending on how strongly the need for hardware-based security, you could do some of the following:

1. Install and validate hardware certificates. This process can usually be automated and provides a cryptographic mechanism for hardware assurance. Yes, it can technically be extracted and used on another machine, but then read on.

    

2. Both session.windows_info_os.* and session.windows_machine_info.* give you a ton of (difficult to spoof) data. You could, at the very least:

    

   a. Register each user's machine in a local database (with web/LDAP interface for querying) - you could probably automate the registration process through an APM mechanism.

    

   b. Read and compare things like motherboard, bios, or hard drive serial numbers on subsequent logons.

    

To answer your question, you would place a registry check with the parameters that you would like to have and branch out into a true/false flow.

Example: * User hits your APM/Firepass * Registry check is in the pre-logon sequence * Branch out as true will equal login (bad security but whatever) * Branch out to a false and provide an access denied or different login screen with other resources available to the end user.

Uhh...not quite sure how this got turned around, but I am not trying to query the client. I am trying to perform a standard LDAP Query to my internal domain controller for the client machine name to determine if it is a valid computer account on the domain. Ideally I would then like to check to see if the computer account has the disabled flag set but that is not necessary.

In my policy, first I do an LDAP query for the user account entered on the logon page to determine which branch of the policy they should follow by their group membership, and if it is a user in the IT dept that is eligible for secure network access then I want to validate their client machine to see if they are using a company laptop so they would get the "full" network access list, or if they are using their home computer which is not a domain member so they would get RDP access to one of the management servers.

All my LDAP queries for computer objects fail with "no such member (32)". So my question is can LDAP queries for computer objects work, so I will continue to try to figure it out, or does it not work, in which case I will try to figure out something else. Thanks!!

Well...

That should also be possible. If you look at what session.windows_info_os.last.computer returns, you'll probably see something like this:

|SP3|SP3|MYDOMAIN.COM|SP3.MYDOMAIN.COM|SP3|SP3|MYDOMAIN.COM|SP3.MYDOMAIN.COM|

Not entirely useful as a query itself, considering the computer's object attributes might be any one of these. Example:

cn = SP3
dNSHostName = SP3.MYDOMAIN.COM
sAMAccountName = SP3$

So the first thing we need to do is settle on which object attribute to use, and then which value to use from the returned Windows Info agent. For this example I'll use the full qualified name:

when RULE_INIT {
    set static::THIS_DOMAIN ".mydomain.com"
}
when ACCESS_POLICY_AGENT_EVENT {
    set computer [string tolower [ACCESS::session data get session.windows_info_os.last.computer]]
    foreach x [split $computer "|"] {
        if { $x ends_with $static::THIS_DOMAIN } {
            ACCESS::session data set session.windows_info_os.last.fqdn $x
            return
        }
    }
}

This should return the fully qualified name from that list of names. Now modify the visual policy:

1. Windows Info agent (I stripped all of the branches out)
2. iRule Event agent (to process the above rule)
3. LDAP Query:
    a. Server: previously-created LDAP AAA server
    b. SearchDN = path to computer objects (ex. cn=Computers, dc=MYDOMAIN, dc=COM)
    c. SearchFilter: dNSHostName=%{session.windows_info_os.last.fqdn}
    d. Required Attributes (as required)
    e. Modify the branch rule, replace existing with LDAP Query has Passed

The iRule will extract a single computer name value from the Windows Info agent, and set a temporary variable to stage the LDAP query. The LDAP query will look in the computer DN path for dNSHostName and return success (and a list of LDAP atttributes), or fail.

Hi Kevin,

Thanks again, most appreciated. It works much better when you remember to attach the iRule to the VS. :D

It is closer, different error message now. Modified the domain name to protect the innocent.

LDAP module: query with 'dNSHostName=lastnmxl1311gss.domain.lan' failed: Invalid DN syntax, dn: dc=domain,dc=lan scope: 2 filter: dNSHostName=lastnmxl1311gss.domain.lan (34)

The dNSHostName attribute on the computer object is definitely correct and matches the above. It seems to want the DN format though, which seems like it might be more difficult to construct.

Any chance you can take a capture (ie. WireShark) and take a closer look at the actual LDAP query?

Doh!! Never mind, I had a typo in my scope. I fixed it and the LDAP check is working correctly now. Thanks!!

Mike, you might want to consider multiple verification processes in place to determine access and not rely upon a domain name ldap check. That isn't exactly the safest method ;)

In addition, I'm not sure if you're using the edge gateway or not but the i-rule isn't necessary. There are built in checks to make this work.

Was looking to solve exact same request. Added next step to verify if Machine account is enabled as well. LDAP query Search Filter for Machine account with dNSHostName that is enabled:

(&(dNSHostName=%{session.windows_info_os.machine})(!(userAccountControl:1.2.840.113556.1.4.803:=2)))