So this was just an issue with saving the strategy? The same configuration should absolutely work in 4.2 - all your users should be able to log in the same way. If need be, simply copy the authentication.conf from your 4.1.7 instance into your 4.2. This config file is under $SPLUNK_HOME/etc/system/local Our LDAP integration is largely unchanged in 4.2, with the exception of that strategy page. We now perform some extra validation that the configuration you entered will work. This verification involves contacting the LDAP server a few times and performing some basic searches, so any latency in contacting that server would be reflected in the UI when you hit save. Here is what we now verify for you when you save a strategy (in order): You can contact the LDAP server and bind given the credentials specified. All user base DNs specified exist on the server We can retrieve at least 1 user given the specified username, realname, and groupMapping attributes All group base DNs specified exist on the server We can retrieve at least 1 group given the specified groupName and groupMember attributes Note that the third and fifth checks involve performing a search, which would be subject to size limits. However, we only ask for one entry. So the 'size limit exceeded' is a red herring here; it's just the LDAP server telling Splunk that the search would hit the size limit, even though we only asked for 1 entry. For further information, set ScopedLDAPConnection to debug, which should make it clear exactly what searches we're performing and what's causing the issue. Do this from Manager > System Settings > System Logging ... View more

Doing this correctly requires some knowledge about significant figures and precision. In multiplying by the number .02 (which has 1 significant figure), you limit your result to 1 significant figure. The precision is then set from that result. What you seem to be looking for is exact arithmetic with a precision of 2. The exact() function forces a number to have maximum sigfigs and precision, while the round() function can force your precision. Assuming that count is a non-negative integer, this solution should work for you: eval cost = "$ " . tostring(round(count*exact(.02), 2), "commas") ... View more

You can use the _cd field, which contains "bucket_id:event_offset" for that particular event. I used the following search to find which buckets my events were going into: index=myindex | eval BID = replace(_cd, "(\d+):\d+", "\1") | top BID Remember that bucket IDs only have meaning within that index, not across them. You could easily do things like filter by timerange: index=myindex _time>=1234567890 _time<=1234567899| eval BID = replace(_cd, "(\d+):\d+", "\1") | top BID ... View more

The output is trimmed for those debug messages only, in order to splunkd.log sane. Previously, we would log the entire script output for each invocation, which was much too verbose. For instance, imagine the getUsers() function with thousands of users - we wouldn't want to log that. In the majority of cases, our logger would only report something like "Tried to log a xxx byte message, ignoring..." instead of the intended debug message. Keep in mind this logging output is only meant to provide a brief sanity check on the script. The proper way to debug the script itself is by testing it on its own, without interacting with splunkd. For more information on that, see "Testing the script" in our newly revamped scripted auth docs: http://www.splunk.com/base/Documentation/latest/Admin/ConfigureSplunktousePAMorRADIUSauthentication ... View more