Troubleshooting » History » Version 5
Luke Murphey, 11/02/2018 07:58 PM
1 | 2 | Luke Murphey | {{>toc}} |
---|---|---|---|
2 | 2 | Luke Murphey | |
3 | 1 | Luke Murphey | h1. Troubleshooting |
4 | 1 | Luke Murphey | |
5 | 1 | Luke Murphey | h2. User Accounts from the RADIUS Server Cannot Log In |
6 | 1 | Luke Murphey | |
7 | 1 | Luke Murphey | This can be due to a number of issues. View the related logs with the following search to determine why users cannot log in: |
8 | 1 | Luke Murphey | |
9 | 1 | Luke Murphey | <pre> |
10 | 1 | Luke Murphey | index=_internal ( (UserManagerPro OR HTTPAuthManager) AND sourcetype="splunkd" ) OR sourcetype="radius_auth*" |
11 | 1 | Luke Murphey | </pre> |
12 | 1 | Luke Murphey | |
13 | 1 | Luke Murphey | h2. Roles are Not Being Loaded from the RADIUS Server |
14 | 1 | Luke Murphey | |
15 | 1 | Luke Murphey | Incorrect vendor code or attribute ID is the most common reasons for roles not being loaded from the RADIUS server. Use the following search to view the attributes that are loaded when a user successfully authenticates (note that you will need to successfully login using a RADIUS server user to see the attributes): |
16 | 1 | Luke Murphey | |
17 | 1 | Luke Murphey | <pre> |
18 | 1 | Luke Murphey | index=_internal "Received the following fields upon login" sourcetype="radius_auth" |
19 | 1 | Luke Murphey | </pre> |
20 | 1 | Luke Murphey | |
21 | 1 | Luke Murphey | h2. Splunk is Still Using the Credentials from my Local Account |
22 | 1 | Luke Murphey | |
23 | 1 | Luke Murphey | Users will be authenticated via RADIUS _unless_ they have a local account. Splunk gives local accounts priority over scripted auth users and therefore will not use RADIUS for accounts where a local account already exists. |
24 | 1 | Luke Murphey | |
25 | 1 | Luke Murphey | h2. Authentication Test on Setup Screen Fails Indicating "Unable to validate credentials against the server ..." |
26 | 1 | Luke Murphey | |
27 | 1 | Luke Murphey | The logs likely provide more details regarding why the authentication attempt failed. You can see the relevant logs by searching for the sourcetype "radius_auth" in the internal index: |
28 | 1 | Luke Murphey | |
29 | 1 | Luke Murphey | index=_internal sourcetype="radius_auth" |
30 | 1 | Luke Murphey | |
31 | 1 | Luke Murphey | The log message will probably look something like "Exception triggered when attempting to contact the RADIUS server" and should include details regarding why the authentication attempt failed. |
32 | 1 | Luke Murphey | |
33 | 3 | Luke Murphey | h2. The Setup Screen Fails Indicating That The REST Handler Failed (on Splunk 6.0+) |
34 | 1 | Luke Murphey | |
35 | 1 | Luke Murphey | This is due to a bug in Splunk which causes it to no longer tell users that the input was invalid. Most likely, something is wrong with the input. Likely problems are: the test user account information could not validate (if provided) or the attribute ID for getting the roles information is incorrect. |
36 | 3 | Luke Murphey | |
37 | 3 | Luke Murphey | h2. I have users listed in Splunk that no longer exist; how do I remove them? |
38 | 3 | Luke Murphey | |
39 | 3 | Luke Murphey | The RADIUS app has no way to know whether or not users have been removed. This means you may have users listed in Splunk that could no longer authenticate (since the RADIUS would reject them) but still appear in the user list. These can be removed by using the clearradiuscache search command that is included with version 1.4 and later. |
40 | 3 | Luke Murphey | |
41 | 3 | Luke Murphey | To use it, assign the necessary user account the permission "clear_radius_user_cache" or use an account with "admin_all_objects". |
42 | 3 | Luke Murphey | |
43 | 3 | Luke Murphey | Next, run the search command to clear the cache of the given users. You can run it on individual user accounts or you can have the command delete entries for users that have not authenticated for a certain time. |
44 | 3 | Luke Murphey | |
45 | 3 | Luke Murphey | Below is an example that drops users that have not authenticated within the last 30 days: |
46 | 3 | Luke Murphey | |
47 | 3 | Luke Murphey | <pre> |
48 | 3 | Luke Murphey | | clearradiuscache days_ago=30 |
49 | 3 | Luke Murphey | </pre> |
50 | 3 | Luke Murphey | |
51 | 3 | Luke Murphey | You can also run a test just to see what entries the command would remove before running it: |
52 | 3 | Luke Murphey | |
53 | 3 | Luke Murphey | <pre> |
54 | 3 | Luke Murphey | | clearradiuscache days_ago=30 test=1 |
55 | 3 | Luke Murphey | </pre> |
56 | 3 | Luke Murphey | |
57 | 3 | Luke Murphey | You can also remove a particular users from the list too: |
58 | 3 | Luke Murphey | |
59 | 3 | Luke Murphey | <pre> |
60 | 3 | Luke Murphey | | clearradiuscache user="bob" |
61 | 3 | Luke Murphey | </pre> |
62 | 3 | Luke Murphey | |
63 | 5 | Luke Murphey | The user will not be removed from the user's list instantly. Just wait for a few minutes them to be removed. |
64 | 5 | Luke Murphey | |
65 | 3 | Luke Murphey | It is important to note that removing an entry from the cache does not prevent them from re-authenticating. Instead, it just prevents Splunk from listing them in the user list (until they authenticate again). |