Hi Joshua, 2011/4/6 joshua.gruber <[email protected]>: > Quick answer: I found a work-around, but I believe that the rules > 1817x in msauth_rules.xml do not currently work in the stock rule > sets. > > As I mentioned before, I had already tried restarting both client and > agent--services and the whole servers. No luck. Fortunately this > event happens about once every 30 seconds in my organization so it is > easy to re-create. I'm convinced the reason the logtest was behaving > is that what I posted to is (and above) is from the ossec logs and is > therefore pre-processed data. I don't know of a good way to intercept > the data transmitted by the windows agent. (Though I'd love to know > one, I'm new to OSSEC.) > > After many trials, the following rule worked: > > <rule id="118139" level="1"> > <if_sid>18139</if_sid> > <regex>Failure Code:\s\t0xe</regex> > <description>Windows DC enforcing new encryption types</ > description> > <group></group> > </rule> > > > As did a match with a space followed by a tab in there (which, I'm > told, is lighter on the CPU.) I'm using this latter one, although I'm > not pasting it here as I don't know if it would be better or worse to > have a rule posted that you might not be able to copy over. > > This leads me to believe that the rules for 18170, 18171, and 18172 > aren't working, either. The root cause is likely somewhere else, be > that decoder or code for the agents, but I don't believe those rules > work as written. > > I'll have a little more information in a day or two: I have an old > thin client at a distant site that needs a new clock battery, every > morning it seems to create a Failure Code 0x25 in my event logs, I'll > see if it triggers a 18172 or a 18139. >
I don't have an AD setup to test with, so if you definitely find any such issues please let us know.
