Join over 3 million cybersecurity professionals advancing their career
Sign up with
Required fields are marked with an *
Already have an account? Sign In »
6 hours 3 minutes
Hello and welcome back to the Splunk Enterprise Certified Administrator course on Cyber. In this video, we're gonna be doing a lab to go over how you can create a user and a role within Splunk. So pretty straightforward. But we'll just get started. We're gonna be dealing with splints, native authentication.
So we'll go to settings
Andi, we'll create a new one,
and you can see here. We need to assign a roll down here. So let's just go over this really quick. So first, you to sign a name if you want to. You could set a full name email address. You have to set a password. Obviously, if you want to set these preferences, you can. But you also don't have to do that. And that couldn't be changed later as well.
And then you select a role for that user to belong to. We're not going to use the default rules, So we're actually gonna back out of creating this user and first go create a new role based off of one of these,
and then we'll come back and make our user and assign them to that role. So it's cancelled out of here
go to roles
and we'll add new.
So the very first thing you get to do is inherit from a roll if you want to, you don't have to do this, but it gives you a quick baseline level of capabilities, which is basically just Splunk word for privileges that will be associate with it. So I tend to not
use the default roles and you're not really supposed Teoh. I think, uh,
if the tests asked you anything about using default rolls, you should specify that you should create your own roles based off of them.
So, for example, let's make a new admin role, so we'll create.
We'll go select Admin is our baseline. And so, as you can see, it will automatically add these and the ones that come from the role will say inherited next to him. And then you can feel free to add additional rolls if you want.
So I'm gonna make one that has the delete by keyword, uh, capability as well is everything else and I'm gonna make this, like my absolute like master roll that no one should ever really use them.
So then you can specify which indexes you want them to be able to search. And the trick here
is you can you have to specify both included and default. And so what this means is, if you ever these, you'll be able to see these are going to be the ones that they're allowed to search on. And then these air going to be the ones that when they commit a search without specifying index,
these will be the search, or these will be the indexes that gets surged.
So generally, if I have an admin role, I'm gonna have all internal be my default so you can just run a keyword search and you'll check all internal indexes and then I'll allow them to see all non internal or I'm sorry.
I want non internal to be my default. And I want all internal and all non internal to be searchable.
Then we can see if we want Teoh apply any restrictions you can. So
there's a couple options here you can you can use basically search logic to say what you don't want this user to be able to see. I've
I never really used this, Um,
but if you can think of a security application for why you
like I don't want a certain user to see something. This is just one option that's available to you. Teoh
Till apply in addition to restricting what indexes they can see, so it's worth checking out. It's worth knowing that this feature exists, but how much mileage you get out of it? Might very.
And then, if you want Teoh for the role, you can set a default app. This could be really cool if you make workspace apse, which is basically just a dedicated spot for certain groups of users to use. Like you could make a security app. Or you could make like a Windows admin zap or something,
and just a place to, like, keep them containerized kind of within Splunk.
So this could be kind of cool. If you want to do that, you could just set search. And then this is if you want to set any kind of limitations on their actual search running abilities, which could be really valuable in terms of like limiting how impactful a given user can be
on the system performance
that will just make a name for this and we'll call this, um
mm what's a fun name. Admin is boring. Let's let's call this one Superman. So this is like our this canoe everything kind of role. So we'll create it.
And now we will make a new user
that belongs to that. So users
new user and won't call. This
E. I was gonna call it Superman User, but I'm just not call new user.
And, you know,
in this case, the name is pretty arbitrary. Doesn't really matter. Will make searching, reporting or default app. I'm in Eastern time, so
I'll set this to Eastern time
and we'll get rid of the user capability and, well, Adam toe are Superman role and safe. And so now this guy's created.
So if I were to log out,
I'll be able Teoh. Now log in a lips.
He's not super ran his new user on
or super secure password.
Oh, and I apparently left the box checked for require a new password on log in, which could be good because obviously, since I set the password, I know what it is, and that's no longer that secure.
So that could be a nice security feature. If you want Teoh,
be cognizant of that
cool, but yeah. So that is how you can create a new local Splunk user and a new role. So
that's at a high level. Everything you need to know about that if you get into Mawr Enterprise environments where you're dealing with using some of the more complicated
authentication mechanisms like L DAP, you'll have to go through another,
uh, exercise for doing that splits. Documentation is pretty good, and it's and setting it up is like,
not super complicated. But you do need a sample, um,
loggers or or some sort of information about your, like l dap configuration or active directory configuration so that you can fill in like all the bind and all the all the configurations they ask for.
and then once you do that, you also map
basically a D rolls to Splunk roles. So that process is a little more complicated, and unfortunately, we're not gonna be able to get into it in this course. But just be aware that
that is something you may have to dio. So if you have a test environment available Teoh that can connect to a active directory environment, it would definitely be worth going through that exercise if you have the chance. But aside from that, that's everything you need to know. For
this the exam in terms, off
user creation and roll creation. So that's gonna be the end of this video, and we will see in the next one.