Create Windows records to allow our service to authenticate to your Windows hosts at scan time. Running authenticated scans gives you the most accurate results with fewer false positives. To create Windows records, go to Scans > Authentication and then go to New > Operating Systems > Windows.
For VM/VMDR: Administrator privileges are recommended for the most accurate security assessment and recommended fixes for your system.
For PC/SCA: Administrator privileges (Build-in administrator or 'Domain Admins' groups member account) are required. The administrator privileges are required in order for the compliance scan engine to validate settings on the operating system.
Using an account with administrator privileges allows us to collect information based on registry keys, administrative file shares (such as C$) and running services. For VM/VMDR, it’s possible to use an account with less than administrator rights, however this limits scanning to fewer checks and scans will return less accurate, less complete results.
Using a password vault?Using a password vault?
Go to Scans > Authentication > Vaults and tell us about your vault system. Then choose Authentication Vault in your record and select your vault name. At scan time, we'll authenticate to hosts using the account name in your record and the password we find in your vault.
If you're using a domain account, enter the domain name and select the domain type.
When selected we'll use NetBIOS to authenticate to IP addresses in the domain configuration. You enter IPs in the IPs section of the record. A single authentication record may be defined for an entire domain (tree) using this method.
When selected we'll use NetBIOS to authenticate to hosts in the domain using credentials stored on the domain. If trust relationships exist and the account's permissions are properly propagated, it's possible for us to authenticate to hosts which are not members of the same domain. Learn more
When selected we'll use an Active Directory forest to authenticate to hosts in a certain domain within the framework. You'll need to enter a Fully Qualified Domain Name (FQDN). If "Follow trust relationships" is selected and trust relationships exist, we'll authenticate to hosts in other domains having a trust relationship with the domain you've defined in the record.
Yes, our security service supports trust relationships in Windows domain logins. In other words, you can use credentials stored on one domain to authenticate to one or more hosts stored on another domain when trust relationships are present. This is done by the scan targets automatically, using pass-through authentication.
The "Follow trust relationships" setting (available with Active Directory domain type) is only intended for Small to Midsize businesses that have all of their domains in a single place (for example, a single office). This setting is NOT intended for Enterprise customers with hundreds of domains spread over many locations with firewalls between them.
When this setting is enabled, the scanner needs access to ALL domain controllers of ALL domains in the forest which have a trust relationship with the domain used in the authentication record. If firewalls block the connections to those domain controllers or if they block connections to the DNS servers resolving those domains then this can lead to authentication failures.
Our scanners will attempt authentication to your target hosts using one of the authentication protocols selected in your record, starting with the most secure protocol to the least secure protocol. For domain level authentication, all three protocols are supported. For local host authentication, NTLMv2 and NTLMv1 protocols are supported.
Select the Windows hosts (IPs) you want to authenticate to using the login credentials defined for this record. Each IP may be included in one Windows record.
For domain level authentication, you only select IPs when domain type "NetBIOS, User-Selected IPs" is selected on the Login Credentials tab. All IPs specified in this section must be part of the domain configuration.
If you select "NetBIOS, Service-Selected IPs" or "Active Directory" on the Login Credentials tab, then the IPs section is disabled as you do not enter IPs in records for these domain types.
For Windows Authentication Records without IPs (NetBIOS, Service-Selected IPs or Active Directory), sub-users will be able to see only those Records that they have created, whereas, the records that are created by other users will not be visible to them.
Warning for non-Manager users editing the recordWarning for non-Manager users editing the record
You'll only see the IPs in the record that you have permission to view. The record may actually contain more IPs and any changes you make will affect all hosts defined in the records including the ones you don't see.
If your subscription has Tag Support for Authentication Records enabled, then you'll see additional options for specifying hosts using asset tags. Choose an asset type and then provide IPs or tags to the record. Your asset type options are: IPs/Ranges, IP Range in Tag Rule and Asset Tags.
Note - For domain level authentication, you can only add assets when the domain type is “NetBIOS, User-Selected IPs”. The Assets section is disabled when the domain type is “NetBIOS, Service-Selected IPs” or “Active Directory”.
Use this option to add IP addresses/ranges to the record. Enter the IP addresses/ranges in the field provided.
Use this option to add tags that have IP address ranges defined in the tag rule. All IP addresses defined in the tag rule will be associated with the record, including IPs that don’t already have the tag assigned. Click Add Tag to pick tags to include or exclude. Note that only tags with the dynamic tag rule “IP Address in Range(s)” will be available in the tag selector.
Use this option to add tags to the record for the assets you want included. IP addresses with the selected tags already assigned will be associated with the record. Click Add Tag to pick tags to include or exclude.
Learn more about tag support for authentication records
SMB signing required - This option is unchecked by default, meaning SMB signing is not required. This is the recommended setting. When unchecked, we can authenticate to any Windows version regardless of how SMB signing is configured on the target. You are not protected, however, against man-in-the-middle (MITM) attacks. What happens if I select this option?What happens if I select this option?
When selected, we will require each Windows target to support SMB signing, whether configured through Local Policy or Group Policy. If SMB signing is disabled on a target host, authentication will fail and the host will not be scanned. This option protects against MITM attacks but we won’t be able to authenticate to some hosts.
Minimum SMB version - Select a minimum SMB protocol version, such as version 1, 2.0.2, 2.1, etc, and we’ll require that each Windows target has that version or later. If the target has an older version of the SMB protocol, authentication will fail and the host will not be scanned.
Select the option "Enable agentless tracking" to track the hosts in this record by host ID. During the scanning process, the service assigns a unique host ID to each target host. Learn more
Add as many records as you like. We'll try to match each target host to one record. Learn more
Some compliance checks require that you set the WMI service to run securely by increasing the authentication level to Packet Privacy. Learn how