Start a Conversation
UNSOLVED

JAssociates

updated

13 years ago

J

JAssociates

29 Posts

0

25088

June 12th, 2013 11:00

Cannot access CIFS shares after installing 2008R2 server.

I've deployed a new Windows 2008R2 server in an existing domain with 2 other non-R2 2008 DCs, but my users are having trouble accessing a the EMC fileshare when they are connected to this new server. They cannot access other non EMC shares just fine.

Does anyone have any ideas on what could be wrong?

Here are some details:

1. New server has roles of DNS, DHCP and AD and looks successful from DNS test and from replication of DHCP and AD from other servers.

2. Our celerra file share is named "fileserv" and when users tried to access it through existing drive mapping, they get prompted for Windows Credentials and says "Access is Denied".

3. If I try to access by running \\fileserv, they get the same error.

4. ping tests to fileserv and ip address are successful.

5. If I try to access by running \\ipaddress, they get the same error.

6. "fileserv" name in DNS actually points to same ip address as "emc-san1" (another alias)

7. If I try to access files by using \\emc-san1 , shares ARE accessible and normal.

8. If I try the "net use" cmd, I see that the existing drive mappings to "fileserv" say they are Unavailable.

8. We have load balancing dhcp servers and only users connected to this dhcp server (the new R2 server) are getting this error. Users still connected to the older non-r2 servers are connecting just fine.

9. I even just tried creating a new DNS record called "testserv" and tried to access file shares via \\testserv and get the same error.

10. Just ungraded the software on the celerra from 5.6.47 to 6 and I'm still getting this issue.

11. We have a printer here that has the Scan to File option where it will scan a document and upload it our fileserver while connecting to it via SMB. This feature no longer works after introducing this R2 server into our domain.

12. It's bugging me because ONLY access to the EMC is wonky. All non EMC shares work fine. If I reboot the R2 server, affected users will work for a little while, but then some users can't connect anymore. It almost seems like it is intermittent, or there is a connection limit and then blocks more users.

For the current workaround, I'm remapping to the "emc-san1" for my users to access files.

Note: I still want my users to ultimately connect to fileserv instead of emc-san1 because we might be removing the emc san soon and I can point "fileserv" to the new storage device.

Any ideas on this?

  • K

    kajibade

    33 Posts

    1217

    0

    Posted August 6th, 2013 09:00

    Greetings,

    The output shows that the Celerra Data Mover Max Protocol setting has changed to SMB2 as expected with an upgrade from NAS 5.6 to NAS 6.0. There are a number of different clients connecting with an array of SMB protocol levels.

    CIFS Server is  JA-SM-STORAGE1 on Data Mover Running 6.0.70.4

    Max Protocol = SMB2

    Joined to Domain JUMP

    Current DC = JA-DC1 - A server running W2K8

    JA-DC1 is also a client of JA-SM-STORAGE1 using NT1 protocol <-- Why not connecting with SMB2.02 or SMB2.10?

    There are a number of W2K8 clients accessing shares via SMB2.10

    There are a number of WinXP clients accessing shares via NT1

    There is one W2K client (JUMPSERVER)  accessing shares via NT1

    There is one W2K8 client (JA-NY-SVR)  accessing shares via NT1

    There is one W2K8 client (JA-DC2)  accessing shares via SMB2.02

    There is one W2K8 client (172.20.3.5)  accessing shares via SMB2.02

    However, it is strange that the protocol that


    What is the pattern with the clients that can't connect?

  • J

    JAssociates

    29 Posts

    1217

    0

    Posted August 6th, 2013 10:00

    Kajibade,

    I should point out that we have different servers running different versions of Windows Server, so there are different versions of SMB running. I believe that 2K8 R1 doesn’t support SMB2.1 like 2K8R2 does. Anyways, this is the list:

    JA-DC1 : Win 2K8 R1

    JA-DC2 : 2K8 R1

    JUMPSERVER: W2K

    JA-NY-SVR: 2K8R2

    172.20.3.5 : That is actually JA-DC2…not sure why its showing up like that in your list

    Client machines are a mix of Win XP and Win 7

    I can replicate the pattern if I turn on AD services on JA-DC2. Originally, DC1 and DC2 were our two DCs. I removed AD, DNS, DHCP from DC2, upgraded DART to 6.0 and then re-added the DC roles to DC2. Now, whenever I turn on the AD services on DC2, clients as well as some servers, cannot connect to the CIFS share via a Host record in DNS called “fileserver”, and also cannot connect via
    IP address. They can, however, access it through the JA-SM-STORAGE1 name.

    Does that help with anything?

  • K

    kajibade

    33 Posts

    1217

    0

    Posted August 6th, 2013 11:00

    OK. So it is not about access protocols; it seems to be about name resolution of any A, PTR and alias records setup in DNS when W2K8 R2 Domain Services are enabled.

    What setting is shown when you look at the way the Data Mover plays with Dynamic DNS?

    Use command "server_param -facility dns -info updateMode -verbose " to see what the DM is trying to do when it interacts with the DNS domain.

    This is a display only command (no impact)

  • J

    JAssociates

    29 Posts

    1223

    0

    Posted August 6th, 2013 12:00

    I thought it was R2 related, but JA-DC1 and DC22 are not R2 servers. Does that matter?

    Also, the connectivity doesn’t seem to be affecting ALL DNS names. Clients cannot connect to the CIFS server at
    fileserver
    fileserver> or the CIFS IP Address, but they CAN connect via
    ja-sm-storage1
    ja-sm-storage1> and all other hosts via their A records. It seems as if any NEW DC that is introduced, whether its R2 or R1, will give ‘access is denied’ errors to clients connecting to our CIFS.

    The only workaround I have so far is the STOP AD services on DC2 to ensure all my users can connect to the files.

    Here is the result of the command with DC2 stopped:

    server_param server_2 -facility dns -info updateMode -verbose

    server_2 :

    name = updateMode

    facility_name = dns

    default_value = 2

    current_value = 0

    configured_value = 0

    user_action = none

    change_effective = immediate

    range = (0,2)

    description = Update mode for DNS (default: secure)

    detailed_description

    By default, the Data Mover will issue secure Dynamic DNS updates to the DNS server for the DNS domain it joins. param dns updateMode=0, no updates param dns updateMode=1, insecure updates param dns updateMode=2, secure updates (default)

    Thanks again!

  • K

    kajibade

    33 Posts

    1223

    0

    Posted August 7th, 2013 07:00

    So, now I am wondering if the note mentioned in this Technet article applies. http://technet.microsoft.com/en-us/library/cc753014.aspx

    This references 2008 AD integrated DNS zones requiring clients to use secure dynamic updates.

    The Data Mover here has the setting updateMode=0 (and it was deliberately configured that way, in the past, since it is not the default in NAS 6.0)

    What kind of messages are logged on the Data Mover or in the DNS server when the clients get “Access Denied” errors?

  • J

    JAssociates

    29 Posts

    1223

    0

    Posted August 7th, 2013 10:00

    Do you know how I can check for those messages in the Data Mover? Your commands have been super helpful!

    Can’t we just change the updatemode now that you have a better sense of what kind of servers I’m running?

  • K

    kajibade

    33 Posts

    1224

    0

    Posted August 7th, 2013 13:00

    You can use "server_log -a -s " to show the full log of messages on the running Data Mover, with human-readable date and time stamps. Look for messages related to "DNS" or "GSS-API" that could account for the clients getting "Access Denied" errors. You can also use the event viewer in the Unisphere GUI to see the logs.

    For any cryptic, numerical Message ID's, use the "nas_message -info " command to get a translation.

    Use command "server_param -facility dns -modifyupdateMode -value 2 " to enable secure DNS update behaviour on the Data Mover. I think that this change requires a Data Mover reboot to take effect, so choose a time when you will not impact your business.

  • J

    JAssociates

    29 Posts

    1224

    0

    Posted August 7th, 2013 16:00

    So I turned on DC2 and waiting about 40 minutes because that is how I can replicate this issue. After waiting a while, I tried to have our network scanner scan a document directly to our SAN. Our scanner uses the SMB protocol, btw. As predicted, it errored out and then I collected the log. It was quite long so I just pasted two different sections. The first part is when the scan was successful (with JA-DC2 turned OFF). Then I turned on server and the bottom part is of the error.

    Successful access:

    2013-08-07 16:12:53: SMB: 6: SSX Auth. successful for user jump\scandocs

    2013-08-07 16:12:53: SMB: 7: cifsMangle: Mangling op 3: Input "scandocs", output "scandocs"

    2013-08-07 16:12:53: SMB: 7: cifsMangle: Mangling op 3: Input "JUMP", output "jump"

    2013-08-07 16:12:53: SMB: 6: NTLMSSP1 Empty Blob Len = 9

    2013-08-07 16:12:53: SMB: 6: SSXAuth_SERVER_EXT14 aT=4 mT=3 0x0

    2013-08-07 16:12:53: SMB: 6: SSXDA: completed for uid=0x3f

    2013-08-07 16:12:53: SMB: 6: User JUMP\scandocs primary GID set to 0x8004 (Unix=0x8000)

    2013-08-07 16:12:53: SMB: 6: Successful NTLMSSP Logon for user JUMP\scandocs Client=XRX0000AAD605B9 ntCapa=0x2001

    5202d476 DC0x0096e68418 JA-DC1[JUMP] 44 setCurrentDC Ctx=0x010fec0808 Old=0x0096e68408 New=0x0000000000

    5202d476 DC0x0096e68418 JA-DC1[JUMP] 45 setCurrentDC Ctx=0x0066649808 Old=0x0000000000 New=0x0096e68408

    2013-08-07 16:12:54: SMB: 6: replyNT1[KerbBlob]

    client=172.20.4.1 Port[41954/445] capa=0x8801/0x8000f3fd

    2013-08-07 16:12:54: SMB: 6: NTLMSSP1 flags=0x60088215

    2013-08-07 16:12:54: SMB: 6: SSXAuth_readNTLMSSP1=0x0 Flags=0x60088215

    2013-08-07 16:12:54: SMB: 6: SSXAuth_NTLMSSP1=0xc0000016 Machine='172.20.4.1'

    2013-08-07 16:12:54: SMB: 6: SSXAuth_SERVER_EXT13 aT=3 mT=1 0xc0000016

    2013-08-07 16:12:54: SMB: 6: NTLMSSP2U client=XRX0000AAD605B9 (172.20.4.1 / 172.20.4.1) notASCII=0 Flags=0x60088205

    2013-08-07 16:12:54: SMB: 6: authenticate jump\scandocs S=0 UserAuthenticated

    5202d476 DC0x0096e68418 JA-DC1[JUMP] 48 DCsetNew=0x0096e68408 Old=0x0000000000

    2013-08-07 16:12:54: SMB: 6: SSX Auth. successful for user jump\scandocs

    2013-08-07 16:12:54: SMB: 7: cifsMangle: Mangling op 3: Input "scandocs", output "scandocs"

    2013-08-07 16:12:54: SMB: 7: cifsMangle: Mangling op 3: Input "JUMP", output "jump"

    2013-08-07 16:12:54: SMB: 6: NTLMSSP1 Empty Blob Len = 9

    2013-08-07 16:12:54: SMB: 6: SSXAuth_SERVER_EXT14 aT=4 mT=3 0x0

    2013-08-07 16:12:54: SMB: 6: SSXDA: completed for uid=0x3f

    2013-08-07 16:12:54: SMB: 6: User JUMP\scandocs primary GID set to 0x8004 (Unix=0x8000)

    2013-08-07 16:12:54: SMB: 6: Successful NTLMSSP Logon for user JUMP\scandocs Client=XRX0000AAD605B9 ntCapa=0x2001

    5202d476 DC0x0096e68418 JA-DC1[JUMP] 44 setCurrentDC Ctx=0x0066649808 Old=0x0096e68408 New=0x0000000000

    5202d476 DC0x0096e68418 JA-DC1[JUMP] 45 setCurrentDC Ctx=0x00c115f008 Old=0x0000000000 New=0x0096e68408

    2013-08-07 16:12:54: SMB: 6: replyNT1[KerbBlob]

    client=172.20.4.1 Port[41955/445] capa=0x8801/0x8000f3fd

    2013-08-07 16:12:54: SMB: 6: NTLMSSP1 flags=0x60088215

    2013-08-07 16:12:54: SMB: 6: SSXAuth_readNTLMSSP1=0x0 Flags=0x60088215

    2013-08-07 16:12:54: SMB: 6: SSXAuth_NTLMSSP1=0xc0000016 Machine='172.20.4.1'

    2013-08-07 16:12:54: SMB: 6: SSXAuth_SERVER_EXT13 aT=3 mT=1 0xc0000016

    2013-08-07 16:12:54: SMB: 6: NTLMSSP2U client=XRX0000AAD605B9 (172.20.4.1 / 172.20.4.1) notASCII=0 Flags=0x60088205

    2013-08-07 16:12:54: SMB: 6: authenticate jump\scandocs S=0 UserAuthenticated

    5202d476 DC0x0096e68418 JA-DC1[JUMP] 48 DCsetNew=0x0096e68408 Old=0x0000000000

    2013-08-07 16:12:54: SMB: 6: SSX Auth. successful for user jump\scandocs

    2013-08-07 16:12:54: SMB: 7: cifsMangle: Mangling op 3: Input "scandocs", output "scandocs"

    2013-08-07 16:12:54: SMB: 7: cifsMangle: Mangling op 3: Input "JUMP", output "jump"

    2013-08-07 16:12:54: SMB: 6: NTLMSSP1 Empty Blob Len = 9

    2013-08-07 16:12:54: SMB: 6: SSXAuth_SERVER_EXT14 aT=4 mT=3 0x0

    2013-08-07 16:12:54: SMB: 6: SSXDA: completed for uid=0x3f

    2013-08-07 16:12:54: SMB: 6: User JUMP\scandocs primary GID set to 0x8004 (Unix=0x8000)

    2013-08-07 16:12:54: SMB: 6: Successful NTLMSSP Logon for user JUMP\scandocs Client=XRX0000AAD605B9 ntCapa=0x2001

    5202d476 DC0x0096e68418 JA-DC1[JUMP] 44 setCurrentDC Ctx=0x00c115f008 Old=0x0096e68408 New=0x0000000000

    Failed Access:

    2013-08-07 16:32:16: LDAP: 11: LdapClient::searchOn: client @ = 0x00333c5858, DN = , scope = 0

    2013-08-07 16:32:16: LDAP: 11: LdapService::connect: sslClient is NULL

    2013-08-07 16:32:16: LDAP: 11: LdapUdpXportImpl::read: select timeout = 200

    2013-08-07 16:32:16: LDAP: 11: LdapService::shutdown: @ = 0x00694b9408, connection = 0x00ca042c08

    2013-08-07 16:32:16: LDAP: 11: LdapClient::searchOn: client @ = 0x00333c5858, DN = , scope = 0

    2013-08-07 16:32:16: LDAP: 11: LdapService::connect: sslClient is NULL

    2013-08-07 16:32:16: LDAP: 11: LdapUdpXportImpl::read: select timeout = 200

    2013-08-07 16:32:16: LDAP: 11: LdapUdpXportImpl::read: errno = 5

    2013-08-07 16:32:16: LDAP: 11: LdapService::shutdown: @ = 0x00d2655a08, connection = 0x0007875b08

    2013-08-07 16:32:16: LDAP: 11: LdapClient::searchOn: client @ = 0x00333c5858, DN = , scope = 0

    2013-08-07 16:32:16: LDAP: 11: LdapService::connect: sslClient is NULL

    2013-08-07 16:32:16: LDAP: 11: LdapUdpXportImpl::read: select timeout = 200

    2013-08-07 16:32:16: LDAP: 11: LdapUdpXportImpl::read: errno = 5

    2013-08-07 16:32:16: LDAP: 11: LdapService::shutdown: @ = 0x003011b808, connection = 0x007877aa08

    2013-08-07 16:32:16: LDAP: 11: LdapClient::searchOn: client @ = 0x00333c5858, DN = , scope = 0

    2013-08-07 16:32:16: LDAP: 11: LdapService::connect: sslClient is NULL

    2013-08-07 16:32:16: LDAP: 11: LdapUdpXportImpl::read: select timeout = 200

    2013-08-07 16:32:16: LDAP: 11: LdapService::shutdown: @ = 0x0065ee7408, connection = 0x0048064308

    2013-08-07 16:32:16: LDAP: 11: LdapClient::searchOn: client @ = 0x00333c5858, DN = , scope = 0

    2013-08-07 16:32:16: LDAP: 11: LdapService::connect: sslClient is NULL

    2013-08-07 16:32:16: LDAP: 11: LdapUdpXportImpl::read: select timeout = 200

    2013-08-07 16:32:16: LDAP: 11: LdapService::shutdown: @ = 0x00389cf208, connection = 0x0105648c08

    2013-08-07 16:32:16: SMB: 6: W2KgetInitialDC:favorite DC=JA-DC2 (old=JA-DC1) IP=172.20.3.5/172.20.3.4 domain=jumpassociates.net

    5202d900 DC0x00b5ab5418 JA-DC2[JUMP] 4 setCurrentDC Ctx=0x00b922c008 Old=0x0000000000 New=0x00b5ab5408

    5202d900 DC0x00b5ab5418 JA-DC2[JUMP] 10 IPC_Connect: :ConnectReset PID=0x1001

    5202d900 DC0x00b5ab5418 JA-DC2[JUMP] 11 Try to connect port=445

    2013-08-07 16:32:16: SMB: 6: >DC=JA-DC2(172.20.3.5) R=11 T=1 ms S=0,0x1/-1

    2013-08-07 16:32:16: KERBEROS: 11: krb5_sendto_kdc

    2013-08-07 16:32:16: KERBEROS: 11: krb5use_dns: use dns = yes

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: for service _kerberos at realm JUMPASSOCIATES.NET, # KDC: 2

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: name ja-dc2.jumpassociates.net

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: prior. 0

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: port 88

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: IP @ 172.20.3.5

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: name ja-dc1.jumpassociates.net

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: prior. 0

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: port 88

    2013-08-07 16:32:16: KERBEROS: 11: krb5_locate_srv_dns: IP @ 172.20.3.4

    2013-08-07 16:32:16: KERBEROS: 11: krb5_sendto_kdc: Auto addr 172.20.3.5

    2013-08-07 16:32:16: KERBEROS: 11: krb5_sendto_kdc:

    addr 172.20.3.5 == 172.20.3.4

    2013-08-07 16:32:16: KERBEROS: 11: krb5_sendto_kdc:

    addr 172.20.3.5 == 172.20.3.5

    2013-08-07 16:32:16: KERBEROS: 11: krb5_sendto_kdc:elevate entry addr 172.20.3.5

    2013-08-07 16:32:16: KERBEROS: 11: krb5_sendto_kdc: 2addr 172.20.3.5

    2013-08-07 16:32:16: KERBEROS: 11: krb5_sendto_kdc: proto is TCP

    2013-08-07 16:32:17: KERBEROS: 11: krb5_sendto_kdc:

    addr 172.20.3.5 == 172.20.3.5

    2013-08-07 16:32:17: KERBEROS: 11: krb5_sendto_kdc:first entry addr 172.20.3.5 idx 0 list count 3

    2013-08-07 16:32:17: KERBEROS: 11: krb5_send_tgs: return from krb5_sendto_kdc: retval = 0

    2013-08-07 16:32:17: SMB: 6: KC_buildKrbCred(CIFS/JA-DC2@JUMPASSOCIATES.NET) Send init_sec_context sz=1301 rflags=0x1b6

    2013-08-07 16:32:17: SMB: 6: DC_GetBlob srv=ja-sm-storage1 svc=CIFS@JA-DC2.JUMPASSOCIATES.NET OK (1)

    2013-08-07 16:32:17: SMB: 6: >DC=JA-DC2(172.20.3.5) R=11 T=1 ms S=0,0x1/-1

    2013-08-07 16:32:17: KERBEROS: 11: krb5_sname_to_principal: getHostByNameOrdered - hostname ja-sm-storage1.jumpassociates.net - returned hostname ja-sm-storage1.jumpassociates.net

    2013-08-07 16:32:17: KERBEROS: 11: krb5_get_host_realm : Using realm 'JUMPASSOCIATES.NET' for host 'ja-sm-storage1.jumpassociates.net'

    2013-08-07 16:32:17: KERBEROS: 11: acquire_accept_cred: principal = CIFS/ja-sm-storage1.jumpassociates.net@JUMPASSOCIATES.NET

    2013-08-07 16:32:17: SMB: 6: SSXAKsc host=CIFS@ja-sm-storage1.jumpassociates.net

    2013-08-07 16:32:17: SMB: 6: checkDCBlob:TicketFlags doesn't match 0x17/0x3

    2013-08-07 16:32:17: SMB: 6: SSXKrbChk accept_sec_context='No error. No error. ' (0x0,0) ntStatus=SUCCESS

    2013-08-07 16:32:17: SMB: 6: >DC=JA-DC2(172.20.3.5) R=11 T=1 ms S=0,0x1/-1

    2013-08-07 16:32:17: SMB: 6: buildMbsPassword(0x00c199c208) JA-SM-STORAGE1 vno=3 L=256 maxLength=65535

    2013-08-07 16:32:17: SMB: 6: sendW2KEnumTrustedDomains for srv=JA-SM-STORAGE1 on domain 'JUMP'

    5202d901 DC0x00b5ab5418 JA-DC2[JUMP] 11 DCsetNew=0x00b5ab5408 Old=0x0000000000

    5202d901 DC0x00b5ab5418 JA-DC2[JUMP] 12 DCsetNew=0x00b5ab5408 Old=0x0000000000

    5202d901 DC0x00b5ab5418 JA-DC2[JUMP] 10 DCsetNew=0x00b5ab5408 Old=0x0000000000

    5202d901 DC0x00b5ab5418 JA-DC2[JUMP] 10 DCsetNew=0x00b5ab5408 Old=0x0000000000

    5202d901 DC0x00b5ab5418 JA-DC2[JUMP] 10 DCsetNew=0x00b5ab5408 Old=0x0000000000

    2013-08-07 16:32:17: SMB: 6: replyNT1[KerbBlob]

    client=172.20.4.1 Port[41963/445] capa=0x8801/0x8000f3fd

    2013-08-07 16:32:17: SMB: 6: NTLMSSP1 flags=0x60088215

    2013-08-07 16:32:17: SMB: 6: SSXAuth_readNTLMSSP1=0x0 Flags=0x60088215

    2013-08-07 16:32:17: SMB: 6: SSXAuth_NTLMSSP1=0xc0000016 Machine='172.20.4.1'

    2013-08-07 16:32:17: SMB: 6: SSXAuth_SERVER_EXT13 aT=3 mT=1 0xc0000016

    2013-08-07 16:32:17: SMB: 6: NTLMSSP2U client=XRX0000AAD605B9 (172.20.4.1 / 172.20.4.1) notASCII=0 Flags=0x60088205

    2013-08-07 16:32:17: SMB: 6: authenticate jump\scandocs S=20 SamLogonPipeAccessDenied

    2013-08-07 16:32:17: SMB: 6: authLogon=SamLogonPipeAccessDenied Es=0x0 Em=ACCESS_DENIED U='scandocs' D='jump'

    2013-08-07 16:32:17: SMB: 6: SamLogonPipeAccessDenied DC=JA-DC2 rebuild status=SecureChannelOK

    5202d901 DC0x00b5ab5418 JA-DC2[JUMP] 8 DCsetNew=0x00b5ab5408 Old=0x0000000000

    2013-08-07 16:32:17: SMB: 6: SSXAuth_SERVER_EXT14 aT=4 mT=3 0xc0000022

    2013-08-07 16:32:17: SMB: 6: SSXDA_remove(0x3f,XRX0000AAD605B9) status=0xc0000022 auth=1

    2013-08-07 16:32:17: SMB: 6: SessSetupX failed with ACCESS_DENIED

    5202d901 DC0x00b5ab5418 JA-DC2[JUMP] 4 setCurrentDC Ctx=0x00b922c008 Old=0x00b5ab5408 New=0x0000000000

    2013-08-07 16:32:46: SMB: 6: NTLMSSP1 flags=0xa2088207

    2013-08-07 16:32:46: SMB: 6: SSXAuth_readNTLMSSP1=0x0 Flags=0xa2088207

    2013-08-07 16:32:46: SMB: 6: SSXAuth_NTLMSSP1=0xc0000016 Machine='IBM-MJHFP45'

    2013-08-07 16:32:46: SMB: 6: SSXAuth_SERVER_EXT13 aT=3 mT=1 0xc0000016

    2013-08-07 16:32:46: SMB: 6: NTLMSSP1 Empty Blob Len = 9

    2013-08-07 16:32:46: SMB: 6: SSXAuth_SERVER_EXT14 aT=4 mT=3 0x0

    2013-08-07 16:32:46: SMB: 6: SSXDA: completed for uid=0x53

    2013-08-07 16:32:46: SMB: 6: Successful ANONYMOUS Logon for user \(NULL) Client=IBM-MJHFP45 ntCapa=0x4

    2013-08-07 16:32:50: SMB: 6: DCT=1375918370856 preconnectDC dns

    2013-08-07 16:32:55: SMB: 6: userLogoffX= uid=0x53

    Hopefully that will paint a better picture of what is going on.

    I’m going to enable Secure DNS tonight, during off hours.

    Thanks!

  • P

    Peter_EMC

    674 Posts

    1224

    2

    Posted August 7th, 2013 22:00

    JAssociates wrote:

    I thought it was R2 related, but JA-DC1 and DC22 are not R2 servers. Does that matter?

    Also, the connectivity doesn’t seem to be affecting ALL DNS names. Clients cannot connect to the CIFS server at
    fileserver<file:///
    fileserver> or the CIFS IP Address, but they CAN connect via
    ja-sm-storage1<file:///
    ja-sm-storage1> and all other hosts via their A records.  It seems as if any NEW DC that is introduced, whether its R2 or R1, will give ‘access is denied’ errors to clients connecting to our CIFS.

    So all clients can access the Cifs server of the datamover ja-sm-storage1 using the name ja-sm-storage1.

    Connecting to a cifs share using an alias (or not its original compname) seems to be tricky (f.e. kerberos name checking).

    Take a look at a procedure at Connecting to SMB share with an alias name (CNAME) | HomeWorks's Blog

    The DisableStrictNameChecking parameter needs also to be configured on the datamover, see ETA emc158629

    [nasadmin@beckham ~]$ server_param server_2 -f cifs -info LanmanServer.disableNameChecking -v
    server_2 :
    name = LanmanServer.disableNameChecking
    facility_name = cifs
    default_value = 0
    current_value = 0
    configured_value = 1
    user_action = reboot DataMover
    change_effective = reboot DataMover
    range = (0,1)
    description = Disables checking of the server's principal name of the client's kerberos ticket.

    detailed_description
    When set to 1, this parameter disables the control of the server's principal name of the client's kerberos ticket. The client is then allowed to connect with a DNS alias (please refer to Microsoft article 281308). When set to 0, the client is only allowed to connect using the primary computer name.

  • K

    kajibade

    33 Posts

    1056

    0

    Posted August 8th, 2013 05:00

    Thanks Peter:

    It looks like you have found the real answer.

Dell Support Resources

Latest Solutions

View More