About mattbg

mattbg

I have a user that had created a private data model. The user has left the organization but had created a dashboard that used this data model without setting appropriate permissions and so other users get an error when the dashboard tries to access that specific data model. That all makes sense. However, as a user with admin role, I was not able to see this data model at all (via All Configurations or otherwise). I confirmed that it existed only via the file system (grep on user .conf files) and was then able to create a temporary local user account for the departed user in order to access their knowledge objects and set permissions as needed. Should admin not be able to see and act on private data models? The admin role does have the admin_all_objects privilege as per the default. Splunk Enterprise 8.2.x Thanks in advance.

mattbg · ‎07-12-2022

Thanks again for your replies. Member behaviour on deployer_push_mode=full shows the following. So, while it does push the contents of local, it merges them and the existing config takes precedence, so the encrypted passwords in 'local' don't get updated. This matches what I found when I tested it in my environment this morning: Copies the non-local and non-user configurations to each member's app folder and overwrites the existing contents. Merges local and user configurations with the corresponding folders on the member, such that the existing configuration on the member takes precedence. Another suggestion I've seen is to encrypt the password outside of the app, and then include the encrypted password in the app to be distributed with the bundle. This would work for the SH cluster because the splunk.secret is the same on all nodes, but I'm not sure it would work on indexers because the secrets are different. So, I am still working with the idea that removing the local app passwords on the SHC and Indexer cluster members at the OS level before pushing the bundles out is the way to go for this particular case. Appreciate your feedback - it is making me think 🙂

mattbg · ‎07-11-2022

To add - if the local files are removed before the bundle push, the rolling restart is not required (on an indexer cluster a rolling restart does happen, but it's automatic as part of the bundle push).

mattbg · ‎07-11-2022

@VatsalJagani, thanks for your reply. Both of the cases you describe don't seem to deal with the issue of the local file not being updated when a new password is deployed in a 'default' conf file. This is presumably by design - the local files should not be updated by a deployment because they contain local overrides. Deploying 'local' files in the app would not work either - those files are not designed to be deployed and values already on the host take precedence. So, the first deployment of a password (when no 'local' file is present) works as expected, but subsequent deployments of an updated 'default' conf with a new password do not work because the local file doesn't get updated. There's some suggestion in the Splunk docs that it's a bad idea to deploy passwords via apps - i.e. on an index cluster, you can't even write to slave-apps, so a duplicate app will be created in $SPLUNK_HOME/etc/apps. But, given that this app is very simple (only contains LDAP authentication config) I can live with that for now. I am starting to think that removing the 'local' authentication.conf files in the app and doing a rolling restart is the best way to automate this, but it's dependent on what else you have in those local files. In my case, I only have the password.

mattbg · ‎07-08-2022

Splunk Enterprise 8.2.3.3 on Linux In our implementation, I'm using a cluster app on our Indexer and Search Head clusters to control LDAP authentication. I have two separate apps (due to different authentication needs on each) but essentially the same basic LDAP configuration. This has been working fine since inception but we recently had to update the password used to connect to the LDAP server. I thought it would be a matter of simply updating the password in the 'default' authentication.conf in each of the apps and then deploying an app bundle to each cluster. I assumed that the 'local' authentication.conf, which normally gets created on each node with an encrypted version of the app password, would get updated with a new encrypted password on each of the cluster nodes as part of the bundle push. The bundle deployments worked fine, but LDAP authentication was not working afterwards. The 'local' authentication.conf did not get updated during the app bundle push to either cluster and the way I got it working was: 1. Manually remove the app's 'local' authentication.conf from all of the Indexer and Search Head nodes 2. Do a rolling restart of each cluster After that, the LDAP authentication worked correctly. Is that expected? Is there a better way of doing this? Any issues with my use of 'default' / 'local' for these purposes? Thanks in advance for any thoughts.

mattbg · ‎04-04-2022

We saw this again on some of our Windows UFs that had not yet been upgraded past 8.1.2 (it's the 8.1.5 release notes that show the fix). However, we did not see the issue on any of our UNIX UFs that are on 8.2.5, which is a good sign given that the large majority of our UFs are UNIX.

mattbg · ‎01-18-2022

I had a requirement to do something similar. This is what I did, but if I have the need to scale it further then I may have to revisit parts of it: Create a new role user_standard that inherits from user role (and adds nothing else). Most users are assigned this role. Configure srchIndexesDisallowed in user_standard role to exclude the indexes that should not be accessible to regular users Create another role user_elevated that also inherits from user role but does not restrict via srchIndexesDisallowed This seems to work for what I need while also avoiding the overhead of having to maintain permissions on specific indexes as new indexes are added. As mentioned, if lots of permutations of index access become necessary then this will get messy. It'd be much better if we were able to layer the roles to add/remove permissions, but I can see why Splunk took the approach of most-restrictive access where data access security is concerned.

mattbg · ‎07-22-2021

To close this off, I was advised by support that this is a defect fixed in Splunk 8.1.5 (assume this refers to the UF, but didn't enquire as we have plans to upgrade both Enterprise and the UF to 8.2.x)

mattbg · ‎07-22-2021

I'm currently working on migration of a single-node installation to indexer and search head clusters. Specifically on migrating the scheduled searches and alerts to the SHC, the recommended way of doing this appears to be to use the Deployer to deploy an app containing the configuration to the members. I've tested it - it works - and if I do the initial deployment with the savedsearches.conf in the 'local' directory then it allows the SHC members to make updates via the UI using the standard sync mechanism, and those changes won't get overwritten by future deployments because they are in the 'local' directory. So far so good. But, I am curious - is there anything wrong architecturally with stopping all of the SHC members, replacing the SPLUNK_HOME/etc/apps/search/local/savedsearches.conf with the same, identical file copied from the single-node install on each member, and then bringing them up? I'm led to believe this would work, but I'm also not sure if it would cause any consistency issues with future updates and sync across the cluster. Why would I want to consider doing this? Mainly to avoid having to look for scheduled searches in two places ("search" and "migration" apps) when making updates via the UI, which will be the main way users will add and edit scheduled searches. Any other potential pitfalls with this approach? Or methods that would avoid having to maintain scheduled searches across two apps? I'm only asking here about the scheduled searches. Everything else has been migrated to the correct locations via the indexer/search head cluster mechanisms, so for the purpose of this question you can assume that everything else regarding field extractions, indexes, etc. for those scheduled searches has already been migrated and I just need to migrate the scheduled search definitions. Thanks in advance.

mattbg · ‎04-30-2021

UF -> Indexer It's a small installation; no clustering (yet); all Splunk Enterprise components are on a single node.

mattbg · ‎04-30-2021

Using Splunk UF 8.1.1, we've noticed an issue where the Linux x64 forwarder running on RedHat 7.7 did not seem to correctly adjust for daylight saving time; that is, the timestamps after the DST change are 1 hour ahead of where they should be. We are not using any special TZ configuration on the UF or indexer and have until now relied on the Splunk UF picking up the underlying OS timezone to enrich events which, as I understand from the props.conf spec, is a supported approach. Simply restarting the UF has resolved the issue on multiple servers. The same UF version on Windows did not have this issue. Is this expected behavior? Thanks in advance.

mattbg · ‎11-24-2020

I ended up using this cron expression to run on monthdays 1-7 regardless of the weekday: 0 9 1-7 2,5,8,11 * ...and then filtering my results so that I only got results on Mondays: … | eval today_weekday=strftime(now(), “%w”) | where today_weekday=1 I couldn't use a time range filter because the underlying data can be generated at any time and the alert just sends the most recent results that exist at the start of the quarter.

mattbg · ‎11-17-2020

I'm trying to schedule a particular alert to run on the first Monday of each fiscal quarter using this cron expression: 0 9 1-7 2,5,8,11 1 My reading of this is "9:00am on the first Monday of Feb, May, Aug, and Nov". However, with this month being November (11) for some reason it is running it every Monday. It unexpectedly ran this past Mon Nov 16th and has a "next scheduled time" of Mon Nov 23rd. Given the day-of-month restriction (3rd field) of 1-7 I would not have expected this to happen. Any advice appreciated. Splunk Enterprise 8.0.6. Thanks.

Posts	13
Solutions	1
Karma Given	5
Karma Received	4
Member Since	‎02-25-2020

Online Status	Offline
Date Last Visited	3 weeks ago

Should admin not be able to see and act on private...

Indexer / Search Head clusters and app for LDAP au...

Migrating scheduled searches/alerts from single-no...

Why is Splunk Universal Forwarder timezone incorre...

Alert scheduling - cron expression not working as ...

Should admin not be able to see and act on private...

Re: Indexer / Search Head clusters and app for LDA...

Re: Indexer / Search Head clusters and app for LDA...

Re: Indexer / Search Head clusters and app for LDA...

Indexer / Search Head clusters and app for LDAP au...

Re: Splunk Universal Forwarder timezone incorrect ...

Re: Restricting index access with srchIndexesDisal...

Re: Splunk Universal Forwarder timezone incorrect ...

Migrating scheduled searches/alerts from single-no...

Re: Splunk Universal Forwarder timezone incorrect ...

Why is Splunk Universal Forwarder timezone incorre...

Re: Alert scheduling - cron expression not working...

Alert scheduling - cron expression not working as ...