IV25130: MISSING NBTNS QUERY ACTION TO RESOLVE FOR THE IP ADDRESS OF THE DOMAIN CONTROLLER CAUSING A SCAN TO SKIP WIN-MS-KB CHECKS.

APAR status

• Closed as fixed if next.

Error description

• [Symptom]
  Extracted from Mercury.
  
  ES750 - difference results between 2 scans on same target
  
  [Detailed Description]
  Two scans were run using a ES750 on a Windows 2008 target but
  the results are different.  One scan runs Windows missing
  patches checks while the other does not.  From the provinfo, it
  appears in the case where Windows missing patches checks are
  run, the ES is able to connect to the Domain Controller directly
  to verify the assessment credentials.  While in the other case,
  it could not contact the DC, and subsequently the Windows
  missing patches checks are skipped.  But based on L3
  documentation, the verification of account should strictly be
  performed on the target and not on the DC.  This CR is opened to
  investigate and confirm the correct expected behavior.
  
  [Additional Information]This is the PMR that we discussed where
  the ES actually connected to the DC directly to verify
  credentials.  The snippet are in the file below:
  
  [attachment "analysis1.txt" deleted by Cheston S
  Chan/Atlanta/IBM]
  
  Note the lines preceeded by >>>>>.
  
  The provinfo can also be downloaded from the link below:
  
  ftp://pokgsa/home/c/s/cschan/web/public/44766.000.738.provinfo_I
  TD4SCAN1Z.whbhk.net_123.87.11.105_20120320.tgz
  
  Please let me know what you can derive after your review.
  
  ==========
  Lynn Lowrie <llowrie>, 6/18/2012:
  
  Reviewing the data provided.
  ~
  ---End Comment Update 6/18/2012 5:32:04 PM---
  ________________________________________
  Cheston Chan <cchan>, 6/27/2012:
  Do you have any updates on this CR?
  ---End Comment Update 6/27/2012 9:37:36 AM---
  Attaching my email to L3 here for reference:
  
  Do you have any updates on this CR?   As a reminder, the
  customer is seeing the behavior that sometimes the Windows patch
  checks are skipped if verifyAdminCredentials is enabled in the
  policy when scanning Windows 2008 targets.
  
  Upon further review of the logs and pcap, I discovered some
  interesting facts that I would like to share.  It appears in the
  case of failing the verifyAdminAccount, the ES scanner does not
  run an NBNS name query to resolve for the domain ITD_DOMAIN.  I
  have attached my analysis here to see if you can find the logic
  in the code as to why the ES skipped the NBNS call.
  
  Scan sequence A then B then C then D:
  
  A> Windows Server 2003 at 10.100.0.109
  
  1. During the discovery scan of the Windows Server 2003 target,
  the ES resolved the domain ITD_DOMAIN to IP address through NBNS
  name query
  
  
  2. In the assessment scan, the ES used the cached DC IP address
  to run the scan.  And it contacted the DC to verify the user
  account credentials.
  ES ran the Windows patch checks because verifyAdminAccount
  yielded true.
  
  B> Windows Server 2008 at 10.100.33.6
  
  Both discovery and assessment scans of the Windows Server 2008
  target used the cached domain IP address to verify credentials
  acquired from A>.
  Associated pcap does not show any packet activities of another
  NBNS call so it is most likely using the cached value.
  
  
  ES ran Windows patch checks because verifyAdminAccount yielded
  true using cached domain IP address acquired in A>
  
  C> **** es stop/start scripts were run on the ES scanner.   ****
  
  D> Windows Server 2008 at 10.100.33.5
  
  1. The es stop/start or the expiration of time (10 minutes?)
  removed the cached domain IP address.
  
  2. During the discovery scan, the ES did not send NBNS name
  query to resolve the domain IP address.
  
  
  3. During the assessment scan, the discovery could not resolve
  for the DC IP address but it did not issue NBNS call so domain
  was not resolved.
  
  
  As a result, it skipped the Windows missing patches checks
  because verifyAdminAccount yielded false.
  
  Therefore, the issue is caused by the ES skipped running NBNS
  query to resolve the IP address of the domain NB ITD_DOMAIN.
  
  Please let me know if you have any suggestions.
  ---End Comment Update 7/3/2012 2:07:35 PM---
  ________________________________________
  Lynn Lowrie <llowrie>, 7/13/2012:
  
  Found what we were looking for as far as when we access the CD
  during Account Verification.
  
  If the "Verify account access level before using" check box is
  checked, we check on the target Local and see if the account
  returns as admin. If it does, we see no need to check the domain
  controller for a local account. If the, "Check local group
  membership to verify access level" check box is also enabled, we
  do a check of the groups and users in the Administrators group.
  If the account in question is not found and the, "Access domain
  controllers to verify access level" check box is enabled, then
  we check the domain controller.
  
  First we do an NbtNs call to locate the DC and then we will
  query. We also have functionality that will remember when a
  successful admin account has been found, but I cannot find the
  timeout of when that becomes lost. But when admin level has been
  determined and the account marked as verified, we will remember
  the smb resource for subsequent calls to verifyAccount.
  
  In this case when the call is made to the DC to verify, it has
  passed from the smb resource buffer and the query had to be made
  to verify the admin level.
  ~
  ---End Comment Update 7/13/2012 12:53:58 AM---
  ________________________________________
  
  Cheston Chan <cchan>, 7/20/2012:
  Hi Lynn,
  
  It is great to hear from you.
  
  Thank you for the detail explanation about the logic on
  verifyAdminAccount. Your explanation does match to the scenario
  as extracted from the provinfo, except for points C and D,
  referencing back to the "Scan sequence A then B then C then D"
  in my previous post.  The issue occurred after an es stop/start.
  The fact that the ES could not resolve the DC IP address after
  the es restart tells me that the cached value is most likely
  erased and a new NBNS query should have been performed.
  
  Why did the ES not even attempt to issue a NBNS command to find
  the DC to derive its IP address after it failed to locate the
  user account in the Administrators group on the target, and then
  went ahead to conclude that the Domain cannot be resolved?
  
  Based on your explanation that if "Access domain
  controllers to verify access level" is TRUE, then the ES should
  contact the DC by NBtNS.  Yet it appeared to have skipped this
  action.  Can you look further in the code and see if there are
  any criteria to run the NbtNS logic, which might have caused the
  action to be skipped?
  
  I had gone ahead and pointed out to customer that the account is
  missing in the local Administrator and provided the needed steps
  to add in the account, and waiting for customer's results.  But
  it would be great if the ES can consistently contact the DC if
  the flag is enabled.
  
  ---End Comment Update 7/20/2012 4:38:25 PM---
  ---------------------------------------
  Cheston Chan <cchan>, 7/24/2012:
  Customer's policy does not permit adding another local admin
  account to a target that has already been added to the domain.
  We need to find out why the ES scanner skipped the NbtNS query
  when the logging showed that it is resolving for the IP address
  of the domain controller.
  Do you have any updates from your research in the code?
  ---End Comment Update 7/24/2012 8:13:32 AM---
  

Local fix

• Customer rejected workaround by adding a local admin account to
  the target Administrators group due to his security policy.
  

Problem summary

• Newer Microsoft Operating Systems utilize restricted SAMR
  communication models not implemented in the current release of
  Enterprise Scanner 2.3.
  
  This cannot be addressed in a patch and will have to be
  addressed when a new project is slated.
  

Problem conclusion

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Fix information

Applicable component levels

• R230 PSY

     UP