As Tue says, they are greyed out because they were created by the LDAP
component and not by you or another administrator. It knows this because of the component name and the modifierid that is saved in the row for that entry in the role_assignments table. When this is shown on the screen, the code greys this out since you are not that component or modifier who created it and don't have the rights to change it.
If you run the query he posted, it will show you this. Or, you can use this query in the Config Reports or Ad-hoc
plugin to show you all the system level role assignments, with extra data to show you which row each entry has in the role_assignments table.
u.username AS "User",
r.shortname AS "Role",
ra.id AS "Role_assignments id",
(SELECT username FROM prefix_user WHERE id = ra.modifierid) AS "Modifier"
FROM prefix_role_assignments ra
JOIN prefix_role r ON r.id = ra.roleid
JOIN prefix_user u ON u.id = ra.userid
# system level only
WHERE ra.contextid = 1
(Note: You can use this any SQL tool of course as long as you change the
"prefix_ "marker before the table names to your actual prefix such as
The "Role assignments id" is the id number of the row in the role_ssignments table for that user's role assignment. The component is blank for normal role assignments done by hand. If a plugin or other component created the role, its name will be there.
To fix this you can:
1) Edit the row and change the component to a blank and change the modifierid to your own user id as the admin. This should then allow you to remove the user using the interface in Assign system roles.
2) Delete the row. This is actually what the Assign system roles does when you remove someone from a role manually: it removes the whole role from the table.