DRAC Authentication

Jared list-dell at legroom.net
Mon Feb 23 10:31:28 CST 2009

Well, for me it's not a matter of one vs. the other, but rather both
options would be useful.  I'd like to manage authentication via LDAP so
that, for normal and routine maintenance, administration is done via
named accounts, which gives us a proper audit trail and accountability
for our various admins.  This is, by far, the biggest reason I want I
want to manage this using a central directory.

As for your point about possible network outages, etc., that's certainly
a valid concern.  I wouldn't disable the built-in root/admin account,
and would still keep it up to date with the password reset script I
mentioned, but it'd only exist for emergency purposes only.  Eg., if and
only if you couldn't login to the DRAC using your standard named admin
account, then you would use the built-in local admin account.

I just have issues using shared admin accounts; no accountability  =
easy to abuse.


On 02/22/2009 08:26 AM, Jason Edgecombe wrote:
> I definitely understand the reasons for wanting consistent
> authentication on the DRACs, but I would prefer your script that syncs
> passwords as opposed to having the DRACs rely on an external service.
> How would you fix a server if the LDAP directory was unavailable, like
> say, the local network was down? What if you're trying to fix a broken
> LDAP server using the DRAC, but the DRAC relies on the LDAP server?
> DRAC is the life raft, it should have no dependencies besides power,
> network, and cooling.
> I understand that these concerns can be mitigated with redundant LDAP
> servers, but you can run into weird situations where you can't do
> maintenance on servers while the LDAP server is under maintenance. How
> many shops have a defined maintenance window when all/most maintenance
> must occur?
> This reminds me of the cartoons where the character is stranded on the
> desert island with canned food, but has no can opener.
> All that said, I'm still interested in how to customize the DRAC configs.
> Sincerely,
> Jason

More information about the Linux-PowerEdge mailing list