Highlighted
agurung
2 Bronze

Re: LDAP and GSS-API major error: Miscellaneous failure

Hi peter

initially that is what we thought so we set NS20 to sync time with L-DC1. when we checked time in ns20 and l-dc1 its exactly same.

now we do not know why it is still saying time difference.

thank you

Message was edited by:
akg
0 Kudos
Peter_EMC
3 Zinc

Re: LDAP and GSS-API major error: Miscellaneous failure

The datamover was unable to connect to L-DC1
"Unable to connect to Active Directory server l-dc1.internal.mit (10.0.0.1), port 389"

so maybe to time syncing was also impossible?
0 Kudos
nandas
4 Beryllium

Re: LDAP and GSS-API major error: Miscellaneous failure

Can you also show us the output of the following two commands -

server_cifs server_2
server_date server_2 timesvc stats ntp

It will help understanding your issue.

By the way - It may be wise to open a support case with EMC NAS support for this issue - while we are trying to help you here, which may take longer time.

Thanks,
Sandip
0 Kudos
agurung
2 Bronze

Re: LDAP and GSS-API major error: Miscellaneous failure

Hi Guys

Thanks for your help and i actually had called support this morning and i was told that there could have been some problem with contacting NTP server on that particular time. i am not sure how that could have trigger time skew.

any way i have attached output as you requested perhaps this will make some sense.

[nasadmin@mstorage1 nasadmin]$ server_cifs server_2
server_2 :
256 Cifs threads started
Security mode = NT
Max protocol = NT1
I18N mode = UNICODE
Home Directory Shares DISABLED
Usermapper auto broadcast enabled

Usermapper[0] = [127.0.0.1] state:active (auto discovered)

Enabled interfaces: (All interfaces are enabled)

Disabled interfaces: (No interface disabled)

Unused Interface(s):
if=210_87_42_252 l=210.87.42.252 b=210.87.42.255 mac=0:60:16:1d:1d:90
if=192_168_6_2_Exchange l=192.168.6.2 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=192_168_6_3_SQL l=192.168.6.3 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=192_168_6_95_Virtualservers l=192.168.6.95 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=192_168_6_96_virtualservers_2 l=192.168.6.96 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=192_168_6_10 l=192.168.6.10 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=iscsi_ExchangeData l=192.168.6.71 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=iscsi_ExchangeLog l=192.168.6.72 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=iscsi_msSqlData l=192.168.6.73 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=iscsi_msSqlLog l=192.168.6.74 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=TestMPIO l=192.168.6.80 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=iscsi_exchange2003Data l=192.168.6.75 b=192.168.6.255 mac=0:60:16:1d:1d:8e
if=iscsi_Exchange2003Log l=192.168.6.76 b=192.168.6.255 mac=0:60:16:1d:1d:8e

DOMAIN ACADEMIC FQDN=internal.mitacademy SITE=Default-First-Site-Name RC=89
SID=S-1-5-15-25311a3c-1670357e-247c6e34-ffffffff
DC=LSERVER-1(172.16.32.7) ref=14 time=1 ms (Closest Site)
DC=POKHARA(172.16.32.2) ref=19 time=1 ms (Closest Site)
DC=L-POKHARA(172.16.32.3) ref=9 time=1 ms (Closest Site)
DC=L-POKHARA(172.16.32.120) ref=8 time=1 ms (Closest Site)


***** not sure why there is two entry for DC=L-Pokhara(172.16.32.3 and 172.16.32.120) and 172.16.32.120 doesn't exist anymore.**************

DOMAIN MIT FQDN=internal.mit SITE=Default-First-Site-Name RC=7
SID=S-1-5-15-1edf7ce9-605c78d2-350095-ffffffff
DC=M-SERVER(10.0.0.8) ref=1 time=1 ms (Closest Site)
DC=L-DC1(10.0.0.1) ref=3 time=1 ms (Closest Site)
DC=L-DC2(10.0.0.11) ref=2 time=1 ms (Closest Site)

DC=M-SERVER(192.168.5.5) ref=1 time=0 ms
DC**SMBSERVER(192.168.1.4) ref=1 time=0 ms

CIFS Server DANFE[ACADEMIC] RC=45
Full computer name=danfe.internal.mitacademy realm=INTERNAL.MITACADEMY
if=172_16_32_11 l=172.16.32.11 b=172.16.32.255 mac=0:60:16:1d:1d:90
FQDN=danfe.internal.mitacademy (Updated to DNS)
if=acaDatabackup l=192.168.5.16 b=192.168.5.255 mac=0:60:16:1d:1d:90
FQDN=danfe.internal.mitacademy (Updated to DNS)
Password change interval: 0 minutes
Last password change: Thu Oct 11 23:24:57 2007 GMT
Password versions: 2

CIFS Server MONAL[MIT] RC=3
Full computer name=monal.internal.mit realm=INTERNAL.MIT
Comment='EMC-SNAS:T5.5.30.5'
if=DatabackupNetwork l=192.168.5.15 b=192.168.5.255 mac=0:60:16:1d:1d:90
FQDN=monal.internal.mit (Updated to DNS)
if=10_0_0_21 l=10.0.0.21 b=10.0.0.255 mac=0:60:16:1d:1d:90
FQDN=monal.internal.mit (Updated to DNS)
Password change interval: 0 minutes
Last password change: Mon Jun 16 10:41:47 2008 GMT
Password versions: 2

[nasadmin@mstorage1 nasadmin]$ server_date server_2 timesvc stats ntp
server_2 :
Time synchronization statistics since start:
hits= 6, misses= 0, first poll hit= 1, miss= 0
Last offset: 0 secs, 40214 usecs
Current State: Running, connected, interval=60
Time sync hosts:
0 1 10.0.0.1
0 1 172.16.32.2
0 Kudos
jausburn
1 Copper

Re: LDAP and GSS-API major error: Miscellaneous failure

I know this looked like it was turning towards a time syncronization issue, but I found an interesting correlation with a problem I'm currently having.  Very similiar in nature, except that the minor error I'm receiving is "Server not found in Kerberos database".

Now, the only time this occurs is when one of the data movers is attempting to communicate with our domain controllers which are both w2k8-64bit and virtualized servers.  I'm digging deeper into this and was wondering if there was ever a solution found for this thread.  The forum post says there's been no answer in the last two years and I'm curious if the problem just went away, or if you just learned to live with it

0 Kudos

Re: LDAP and GSS-API major error: Miscellaneous failure

I'm sorry if we weren't clear enough.  The "clock skew" messages only occur if the Data Mover time is more than 5 minutes off of the Domain Controller time to which you are trying to authenticate, so somebody's clock is off.  This is usually an error with the Celerra.  But sometimes it can be an issue with that particular Domain Controller.

The "server not found" messages are a little tougher to decode; there is more than one issue which can cause such a message.  If you haven't done so already, open a Service Request to clear that up.

0 Kudos