iDRAC Express and SSO on a SBS 2011 Server

Hello Mark

I don't think the DNS issue has anything to do with the 1 port restriction from SBS. The partitioned portion of LOM1 that the iDRAC is using is not presented to the operating system. As far as the operating system is concerned it is a separate NIC/LOM.

Are you able to access the iDRAC web interface from the server? Have you performed all of the steps in the setup guide for single sign on?

<ADMIN NOTE: Broken link has been removed from this post by Dell>

Thanks

Thanks for this. I have performed all the other steps - and have it working for OMSA.

I can access the iDRAC web interface from a workstation on the network via ping and a browser but cannot ping the IP address of the iDRAC from the server (it returns destination host unreachable)

I think I can access the iDRAC web page from the server but it is being blocked by IE's enhanced security configuration (I see a black background page!).

The log I get when I test the connection is below:

07:35:40 Initiating Directory Services Settings Diagnostics:

07:35:40 principal name from keytab: HOST/xxxxxxxxxxxxxxxxxxxxxxxxxxxx

07:37:40 getting TGT failed: check date/time and time zone offset.

07:37:40 trying DC server xxxxxxxxxxxxx:389

07:37:40 Server Address xxxxxxxxxxxxxxx resolved to xxxxxxxxxxx

07:37:50 ERROR: ping xxxxxxxxxxxxx failed

07:37:50 trying DC server xxxxxxxxxxxxxxx:636

07:37:50 Server Address xxxxxxxxxxxxx resolved to xxxxxxxxxxxxxx

07:38:00 ERROR: ping xxxxxxxxxxxxfailed

and the blanked out IP address is the IP address of the DNS server (sited behind the network port shared with the iDRAC)

So I can only assume that the shared port does not route traffic between itself?

Thanks

Mark

I have just found this paper: support.dell.com/.../iDRAC6Security.pdf

where it states 'Outgoing packets from the iDRAC6 are sent onto the network, but it is physically impossible to send a packet through the network adapter to the host processor'

This means that the DNS packets can't route to the host and is probably my issue. For the case of a iDRAC on a DC or DNS server this is not very helpful!!! Is there any easy way to switch off this security when the iDRAC is in a DC or DNS server - or at least ask for an enhancement....

Thanks

Mark

This means that the DNS packets can't route to the host and is probably my issue.

No, that is not what it means. What it means is that the LOM does not route internally between the port. The port is partitioned into two virtual ports. The two virtual ports cannot communicate directly. This is a security feature to prevent anyone from bypassing network security by connecting to the iDRAC to reach the other port. All traffic from the iDRAC must go through a switch/router. This means that if the LOM is not connected to a switch/router the two virtual ports cannot communicate. It means that they act like two completely different physical connections in the way that they connect to each other, and are not able to route internally within the LOM and bypass switch security. I hope that clears it up.

07:37:40 getting TGT failed: check date/time and time zone offset..

Make sure the date/time and time zone are set correctly for the server and the iDRAC. If there is more than 5 minutes difference the connection will fail.

I think I can access the iDRAC web page from the server but it is being blocked by IE's enhanced security configuration (I see a black background page!).

The operating system is locked down until you configure it. ICMP(Ping request) are disabled by default to prevent DOS attacks. Also, IESEC is enabled by default and prevents almost all web browser activity. Go to the management utility and disable IESEC, and then add the IP address of the iDRAC into the trusted sites of Internet Explorer.

Thanks

Daniel,

Thanks - ok so I have investigated the time -getractime returns the correct time. There is some discussion on the web around timezones but I can't get either the setractime or getractime -z commands to work (dell iDRAC version 1.92 on an iDRAC Express; RACADM 7.2) so can't see how to check or set the timezone (I am UK based).

I have had a thought on the switch point - it is currently connected to a Netgear JGS516 (which is I believe an unmanaged switch) I could swap it over to a Netgear WGS716Tv2 (which they describe as smart). If all the IP traffic has to leave the server go to the switch and come back to the server. Does that imply I need a layer 2 or 3 switch?

Thanks

Mark

There is some discussion on the web around timezones but I can't get either the setractime or getractime -z commands to work (dell iDRAC version 1.92 on an iDRAC Express; RACADM 7.2) so can't see how to check or set the timezone (I am UK based).

Try these commands for setting it:

/admin1-> racadm config -g cfgRactuning -o cfgRactuneTimezoneOffset
/admin1-> racadm getconfig -g cfgRactuning -o cfgRactuneTimezoneOffset

The iDRAC BIOS time will not reflect the time zone offset, so just make sure you set the proper time zone. It will still show the time without the offset when you check with a command like this:

/admin1-> racadm getractime

If all the IP traffic has to leave the server go to the switch and come back to the server. Does that imply I need a layer 2 or 3 switch?

No, you shouldn't need a managed switch to make it work. If you are able to access the iDRAC and the server from other computers on the network then the networking portion is working fine. When you set up the networking on the iDRAC did you set the IP address for the server as the DNS, or is using the netgear or some remote DNS server for lookups?

ok thanks - the get config returns a timezone offset of 0 minutes which is correct as it is GMT here! So the time and timezone are consistent between server and iDRAC. So I don't know why we get the TGT error - I wonder if it is related to the switching issue as well and we just are getting a misleading error message.

I am setting the server's IP address as the DNS server on the iDRAC (on the grounds that DNS won't be running when the iDRAC boots up). It's only a small network so there is no redundant DNS at the moment.

I have also switched off the IE Enhanced security and can confirm that I cannot access the iDRAC via HTTP from the server (but can from workstations) so the packets are not getting from the server to the iDRAC and back again. I though that most switches didn't send packets out on the port they arrive on so think this must be the problem. i will try swapping the switches over next weekend and see if there is any better behaviour.

Regards

mark

Thanks for you efforts on this.

OK so by invoking the ping command from my workstation the default gateway, iDRAC and server get a response. Pinging from the DRAC I can ping the default gateway or my workstation and get a response. However pinging the server IP from the iDRAC I get no response.

I see two candidates here -  the switch or something to do with IPv6. I will swap the switch over as the next idea (I think it is just the problem of not routing back from whence it came)

Thanks

Mfrk

I am setting the server's IP address as the DNS server on the iDRAC

That should work. Since SBS is the DNS server for the domain that is DNS address that should be used on the DRAC and all other items on the domain.

I though that most switches didn't send packets out on the port they arrive on so think this must be the problem

That is not necessarily true. Even though they are on the same physical port the two virtual ports have different mac addresses. The switch/router will send all packets destined for either location through the same physical port. The LOM will send packets destined for the DRAC MAC address and IP to the DRAC, and the the ones with the server MAC and IP to the server port. I don't know of any switches/hubs/routers that cannot perform this task. If this were limited to managed switches/routers then most people would not be able to connect to VPNs, virtual machines, and other virtual infrastructure that passes traffic for many virtual network interfaces through a single physical port.

I would suggest troubleshooting the DRAC and server configuration. Make sure the domain name is set correctly in the DRAC. Also, try disabling all firewalls and security settings to make sure communication is not being blocked. Have you had any issues registering computers on the domain?

Pinging from the DRAC I can ping the default gateway or my workstation and get a response. However pinging the server IP from the iDRAC I get no response.

Yep, that narrows it down to a communication problem between the DRAC and server. It might be a routing issue with the switch, let me know how it goes.

Thanks

OK -so some progress. Adding a second network cable and changing the enabled one in the OS has allowed me to have one working network card for the OS and one for the DRAC and they can now see each other.

So the logs now show

09:48:25  Initiating Directory Services Settings Diagnostics:
09:48:25  principal name from keytab: HOST/[server name].[domain.local]@[domain.local]
09:48:26  getting TGT failed: check date/time and time zone offset.
09:48:26  trying DC server [server name].[domain.local]:389
09:48:26  Server Address[server name].[domain.local] resolved to xx.xx.xx.xx
09:48:26  connect to xx.xx.xx.xx:389 passed
09:48:26  trying DC server [server name].[domain.local]:636
09:48:26  Server Address [server name].[domain.local] resolved to xx.xx.xx.xx
09:48:26  connect to [server name].[domain.local]:636 passed
09:48:27  Connecting to ldaps://[server name].[domain.local]:636...
09:48:27
  ERROR: bind failed: Invalid credentials, 80090308: LdapErr:
DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1:
user=[address}@[domain.local]
host=[server name].[domain.local]

The time and timezone are consistent between drac and server... but I assume the TGT message is the cause of the invalid credentials. Any further thoughts of areas to investigate?

THanks
Mark

I suspect the credentials are not entered in the expected format. Enter the username without a domain prefix or suffix, and try with just the domain name and also with the FQDN. Also, check the logs on the server to see if a login is being rejected.