san wont authenticate against 2008 dc

[bart21]

Hi people

 

we have a netapp fas 270 SAN, which has been doing fine authenticating to the 2003 domain controllers.

 

We have upgraded all the dc's to 2008 except for one. We want to upgrade this one so switched it off to ensure everything runs smoothly, and it doesnt!

 

When the 2k3 domain controller is switched off the san says it cannot connect to the 2k8 dc's. This is affecting file permissions.

 

So is there any way to lower the authentication level to the same level as 2003.

 

nick

[3s-gtech]

This may be a firmware issue for the SAN - check to see if an update is available.

[Azhibberd]

Any chance you have maybe enabled LDAP server signing required? which maybe the san doesnt support, Although first port of call would be as gtech said... Firmware!

[bart21]

thanks for your replies, The san is 4 years old. We did, until 2 years ago have a netapp support contract which included firmware. The head then refused to pay for it, said it wasnt worth the amount being charged. To obtain firmware now we would have to go back on support, and its a no from the head.

 

Surely the problem is that server 2008 has increased security, can that be set to 2003 level?

 

If i get my way the SAN will be replaced at the age of 6 years.

 

thanks

 

nick

[SYNACK]

Try disabling all the good LDAP security bits from 2008 as follows:

Server 2008 and NAS

If the issue persists, please try to disable the following security policy for Domain to test:

Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options

Domain Controller: LDAP server signing requirements – NONE

Domain member: Digitally encrypt or sign secure channel data (always) – DISABLED

Domain member: Digitally encrypt secure channel data (when possible) – DISABLED

Domain member: Digitally sign secure channel data (when possible) – DISABLED

Domain member: Require strong (Windows 2000 or later) session key – DISABLED

Microsoft network client: Digitally sign communications (always) – DISABLED

Microsoft network client: Digitally sign communications (if server agrees) – DISABLED

Microsoft network server: Digitally sign communications (always) – DISABLED

Microsoft network server: Digitally sign communications (if client agrees) – DISABLED

Network security: LAN Manager authentication level - Send LM & NTLM - use NTLMv2 if negotiated

If no progress, try the steps below:

Step 1: Enable the group policy Allow cryptography algorithms compatible with Windows NT 4.0 in the domain.

1) Log on to a Windows Server 2008-based domain controller.

2) Click Start, click Run, type gpmc.msc, and then click OK.

3) In the Group Policy Management console, expand Forest: DomainName, expand DomainName, expand Domain Controllers, right-click Default Domain Controllers Policy, and then click Edit.

4) In the Group Policy Management Editor console, expand Computer Configuration, expand Policies, expand Administrative Templates, expand System, click Net Logon, and then double-click Allow cryptography algorithms compatible with Windows NT 4.0.

5) In the Properties dialog box, click the Enabled option, and then click OK.

6) Apply the policy to all DCs.

 

Or just tell the head that you need that "un-nessisary support contract" if he wants to see his documents ever again.

[bart21]

hi

 

i have tried the above, no luck. I have posted below the San admin interface error when trying to see the dc's.

 

"..Not able to communicate with PDC 10.*.*.15

trying 10.*.*.15...10.*.*.15 is alive

found PDC EXCALIBUR at 10.*.*.12

..Not able to communicate with PDC 10.*.*.17

trying 10.*.*.17...10.*.*.17 is alive

..Not able to communicate with PDC 10.*.*.18

trying 10.*.*.18...10.*.*.18 is alive

..Not able to communicate with PDC 10.*.*.16

trying 10.*.*.16...10.*.*.16 is alive"

 

 

as you can see, it can see the 2k3 (excalibur) but can see the rest just not connest to them

 

any ideas?

 

nick

[SYNACK]

Is it using credentials to access the LDAP server or trying an annonomys connection and also have you checked out the traffic flow using wireshark to see exactly what it is asking for from the servers that are not responding. It could be trying to use a different port or different version of LDAP or something.

[Azhibberd]

i'm guessing you have tried turning the firewall off on the dc just to test? also have you checked the time and date are right on the san but as it seems fine with the 2003.. im guessin thats fine

[bart21]

Thanks for your reply, firewall is off and time is fine

 

nick

[bart21]

Hi synack

 

i think it is using credentials i will try wireshark now. Where can i get it?

[bart21]

Have used wireshark on both dc's (the 2003 and a 2008)

 

the problem appears to be a header checksum.

 

The san makes a session request to the 2008, the 2008 replies with the wrong checksum. Wireshark shows an error, which says wrong checksum. This is obvioustly what is wrong.

 

The 2k3 sends the correct checksum which is why it connects.

 

see pics

 

anyone any ideas why 2008 is sending wrong checksum??

 

thanks nick

[SYNACK]

I'm more interested in why its trying to use netbios to access the authentication information. How is the delegation setup on the SAN and can it be set to raw LDAP. It looks like it is trying to use older Windows protocols that are probably disabled or implemented differently. It should be hitting TCP port 389 to grab the information via LDAP.

 

You could try re-enabling NTLMv1 stuff which may allow the current way to work: Allow Windows Vista, Server 2008 systems to interact with older Samba installations | Network Administrator | TechRepublic.com

http://www.activedir.org/ListArchives/tabid/55/forumid/1/postid/40550/view/topic/Default.aspx

 

Keep a note of it though as all of this has got to be pokeing massive holes in the security of your network servers and you will want to reverse it when you get newer hardware.

[featured_spectre]

Synack is almost BANG on as we did what he has stated and our SAN authenticated fine afterwards...we had to shove our ISA up a few notches to fill the gaps that the server had.

 

only thing you need to do is you need to open TCP AND UDP port 389, so you can grab the LDAP info, and have it working properly.