Guest Charles Posted May 7, 2008 Posted May 7, 2008 We had a few Windows servers that had the last batch of Windows Updates installed and were not rebooted (there was a box indicating that a reboot was required on the desktop). We noticed that a user account that is used on many services on these servers was getting locked out on the domain controllers every couple of minutes. We finally resolved the issue by rebooting the servers. What makes this odd is that the source of the authentication request aws from JCIFS18_15_5D and JCIFS18_145_ED. These machines do not exist on our network. We scanned our network and did not find them. We did a NETSTAT -a and no host was found. My question is this: Does anyone know what JCIFS18_15_5D is? We're thinking that maybe these are IDs for services that were attempting to authenticate to the DCs. Could someone verify this? Thanks.
Guest Meinolf Weber Posted May 7, 2008 Posted May 7, 2008 Re: JCIFS18_15_5D Hello Charles, Please post the complete event viewer entry where these names are stated. Also did you check DNS for them? Is the naming according to your internal naming convention? And ofcourse you should reboot the servers after installing patches, so that also registry keys could update for example, otherwise some patches have no effect. Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights. ** Please do NOT email, only reply to Newsgroups ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > We had a few Windows servers that had the last batch of Windows > Updates installed and were not rebooted (there was a box indicating > that a reboot was required on the desktop). We noticed that a user > account that is used on many services on these servers was getting > locked out on the domain controllers every couple of minutes. We > finally resolved the issue by rebooting the servers. > > What makes this odd is that the source of the authentication request > aws from JCIFS18_15_5D and JCIFS18_145_ED. These machines do not > exist on our network. We scanned our network and did not find them. > We did a NETSTAT -a and no host was found. > > My question is this: > > Does anyone know what JCIFS18_15_5D is? We're thinking that maybe > these are IDs for services that were attempting to authenticate to the > DCs. Could someone verify this? > > Thanks. >
Guest Charles Posted May 8, 2008 Posted May 8, 2008 Re: JCIFS18_15_5D Below is the text from the event log: The domain controller attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: MAGREL Source Workstation: \\JCIFS18_143_B5 Error Code: 0xc000006a Yes, we checked the DNS and the names were not in there. We also have a Cisco wireless network where we searched for the PC names but did not find them. No...this is not a naming convention for our network. This is the first time we were unable to locate a host on our network which is why we thought that these names may be legitimate services attempting to authenticate since the user name "MAGREL" is a legitimate user name used by services on some of our servers (the ones that required a reboot from the Windows updates). Also, remember that the issued went away after we rebooted the servers. Here are a few of the source names we found: JCIFS18_143_B5 JCIFS18_15_5d JCIFS18_145_ed As you can see, all of the mystery names begin with JCIFS18. Is this the format used by Windows for services attempting to authenticat to domain controllers? Please verify. From the above names, it appears that this is a naming convention used by some OS or service. Does anyone recognise this naming convention? Thanks. "Meinolf Weber" wrote: > Hello Charles, > > Please post the complete event viewer entry where these names are stated. > Also did you check DNS for them? Is the naming according to your internal > naming convention? > And ofcourse you should reboot the servers after installing patches, so that > also registry keys could update for example, otherwise some patches have > no effect. > > Best regards > > Meinolf Weber > Disclaimer: This posting is provided "AS IS" with no warranties, and confers > no rights. > ** Please do NOT email, only reply to Newsgroups > ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > > > We had a few Windows servers that had the last batch of Windows > > Updates installed and were not rebooted (there was a box indicating > > that a reboot was required on the desktop). We noticed that a user > > account that is used on many services on these servers was getting > > locked out on the domain controllers every couple of minutes. We > > finally resolved the issue by rebooting the servers. > > > > What makes this odd is that the source of the authentication request > > aws from JCIFS18_15_5D and JCIFS18_145_ED. These machines do not > > exist on our network. We scanned our network and did not find them. > > We did a NETSTAT -a and no host was found. > > > > My question is this: > > > > Does anyone know what JCIFS18_15_5D is? We're thinking that maybe > > these are IDs for services that were attempting to authenticate to the > > DCs. Could someone verify this? > > > > Thanks. > > > > >
Guest Meinolf Weber Posted May 8, 2008 Posted May 8, 2008 Re: JCIFS18_15_5D Hello Charles, Please post the complete event log, just press the 2 paper button in the right corner and paste it to the posting, so the complete error is here. This names will be no service from authentication or something else, this specifies machine names. Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights. ** Please do NOT email, only reply to Newsgroups ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > Below is the text from the event log: > > The domain controller attempted to validate the credentials for an > account. > > Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 > Logon Account: MAGREL > Source Workstation: \\JCIFS18_143_B5 > Error Code: 0xc000006a > Yes, we checked the DNS and the names were not in there. We also have > a Cisco wireless network where we searched for the PC names but did > not find them. No...this is not a naming convention for our network. > > This is the first time we were unable to locate a host on our network > which is why we thought that these names may be legitimate services > attempting to authenticate since the user name "MAGREL" is a > legitimate user name used by services on some of our servers (the ones > that required a reboot from the Windows updates). Also, remember that > the issued went away after we rebooted the servers. > > Here are a few of the source names we found: > > JCIFS18_143_B5 > JCIFS18_15_5d > JCIFS18_145_ed > As you can see, all of the mystery names begin with JCIFS18. Is this > the format used by Windows for services attempting to authenticat to > domain controllers? Please verify. From the above names, it appears > that this is a naming convention used by some OS or service. Does > anyone recognise this naming convention? > > Thanks. > > "Meinolf Weber" wrote: > >> Hello Charles, >> >> Please post the complete event viewer entry where these names are >> stated. >> Also did you check DNS for them? Is the naming according to your >> internal >> naming convention? >> And ofcourse you should reboot the servers after installing patches, >> so that >> also registry keys could update for example, otherwise some patches >> have >> no effect. >> Best regards >> >> Meinolf Weber >> Disclaimer: This posting is provided "AS IS" with no warranties, and >> confers >> no rights. >> ** Please do NOT email, only reply to Newsgroups >> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm >>> We had a few Windows servers that had the last batch of Windows >>> Updates installed and were not rebooted (there was a box indicating >>> that a reboot was required on the desktop). We noticed that a user >>> account that is used on many services on these servers was getting >>> locked out on the domain controllers every couple of minutes. We >>> finally resolved the issue by rebooting the servers. >>> >>> What makes this odd is that the source of the authentication request >>> aws from JCIFS18_15_5D and JCIFS18_145_ED. These machines do not >>> exist on our network. We scanned our network and did not find them. >>> We did a NETSTAT -a and no host was found. >>> >>> My question is this: >>> >>> Does anyone know what JCIFS18_15_5D is? We're thinking that maybe >>> these are IDs for services that were attempting to authenticate to >>> the DCs. Could someone verify this? >>> >>> Thanks. >>>
Guest Charles Posted May 8, 2008 Posted May 8, 2008 Re: JCIFS18_15_5D Our DCs are Server 2008...No idea what you mean by "the 2 paper button in the right corner" but hree are the details I was able to copy and paste: Log Name: Security Source: Microsoft-Windows-Security-Auditing Date: 5/6/2008 9:25:31 AM Event ID: 4776 Task Category: Credential Validation Level: Information Keywords: Audit Failure User: N/A Computer: BRCHDC01.brch.com Description: The domain controller attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: MAGREL Source Workstation: \\JCIFS18_143_B5 Error Code: 0xc000006a Event Xml: <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> <System> <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> <EventID>4776</EventID> <Version>0</Version> <Level>0</Level> <Task>14336</Task> <Opcode>0</Opcode> <Keywords>0x8010000000000000</Keywords> <TimeCreated SystemTime="2008-05-06T13:25:31.271Z" /> <EventRecordID>8828341</EventRecordID> <Correlation /> <Execution ProcessID="612" ThreadID="1564" /> <Channel>Security</Channel> <Computer>BRCHDC01.brch.com</Computer> <Security /> </System> <EventData> <Data Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data> <Data Name="TargetUserName">MAGREL</Data> <Data Name="Workstation">\\JCIFS18_143_B5</Data> <Data Name="Status">0xc000006a</Data> </EventData> </Event> Is it possible that Windows somehow lost it's machine name from the updates and reverted back to it's default machine name until it was rebooted? Charles "Meinolf Weber" wrote: > Hello Charles, > > Please post the complete event log, just press the 2 paper button in the > right corner and paste it to the posting, so the complete error is here. > This names will be no service from authentication or something else, this > specifies machine names. > > Best regards > > Meinolf Weber > Disclaimer: This posting is provided "AS IS" with no warranties, and confers > no rights. > ** Please do NOT email, only reply to Newsgroups > ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > > > Below is the text from the event log: > > > > The domain controller attempted to validate the credentials for an > > account. > > > > Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 > > Logon Account: MAGREL > > Source Workstation: \\JCIFS18_143_B5 > > Error Code: 0xc000006a > > Yes, we checked the DNS and the names were not in there. We also have > > a Cisco wireless network where we searched for the PC names but did > > not find them. No...this is not a naming convention for our network. > > > > This is the first time we were unable to locate a host on our network > > which is why we thought that these names may be legitimate services > > attempting to authenticate since the user name "MAGREL" is a > > legitimate user name used by services on some of our servers (the ones > > that required a reboot from the Windows updates). Also, remember that > > the issued went away after we rebooted the servers. > > > > Here are a few of the source names we found: > > > > JCIFS18_143_B5 > > JCIFS18_15_5d > > JCIFS18_145_ed > > As you can see, all of the mystery names begin with JCIFS18. Is this > > the format used by Windows for services attempting to authenticat to > > domain controllers? Please verify. From the above names, it appears > > that this is a naming convention used by some OS or service. Does > > anyone recognise this naming convention? > > > > Thanks. > > > > "Meinolf Weber" wrote: > > > >> Hello Charles, > >> > >> Please post the complete event viewer entry where these names are > >> stated. > >> Also did you check DNS for them? Is the naming according to your > >> internal > >> naming convention? > >> And ofcourse you should reboot the servers after installing patches, > >> so that > >> also registry keys could update for example, otherwise some patches > >> have > >> no effect. > >> Best regards > >> > >> Meinolf Weber > >> Disclaimer: This posting is provided "AS IS" with no warranties, and > >> confers > >> no rights. > >> ** Please do NOT email, only reply to Newsgroups > >> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > >>> We had a few Windows servers that had the last batch of Windows > >>> Updates installed and were not rebooted (there was a box indicating > >>> that a reboot was required on the desktop). We noticed that a user > >>> account that is used on many services on these servers was getting > >>> locked out on the domain controllers every couple of minutes. We > >>> finally resolved the issue by rebooting the servers. > >>> > >>> What makes this odd is that the source of the authentication request > >>> aws from JCIFS18_15_5D and JCIFS18_145_ED. These machines do not > >>> exist on our network. We scanned our network and did not find them. > >>> We did a NETSTAT -a and no host was found. > >>> > >>> My question is this: > >>> > >>> Does anyone know what JCIFS18_15_5D is? We're thinking that maybe > >>> these are IDs for services that were attempting to authenticate to > >>> the DCs. Could someone verify this? > >>> > >>> Thanks. > >>> > > >
Guest Meinolf Weber Posted May 8, 2008 Posted May 8, 2008 Re: JCIFS18_15_5D Hello Charles, You didn't mention before that it is 2008, the "button" option is from earlier OS. No, the machine name will not go back to whatever it was before, was the server named with this before? Is the server setup for remote access? So that someone from outside can connect via VPN? The Error code C000006A means user name is correct but the password is wrong. Best regards Meinolf Weber Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights. ** Please do NOT email, only reply to Newsgroups ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > Our DCs are Server 2008...No idea what you mean by "the 2 paper button > in the right corner" but hree are the details I was able to copy and > paste: > > Log Name: Security > Source: Microsoft-Windows-Security-Auditing > Date: 5/6/2008 9:25:31 AM > Event ID: 4776 > Task Category: Credential Validation > Level: Information > Keywords: Audit Failure > User: N/A > Computer: BRCHDC01.brch.com > Description: > The domain controller attempted to validate the credentials for an > account. > Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 > Logon Account: MAGREL > Source Workstation: \\JCIFS18_143_B5 > Error Code: 0xc000006a > Event Xml: > <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> > <System> > <Provider Name="Microsoft-Windows-Security-Auditing" > Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> > <EventID>4776</EventID> > <Version>0</Version> > <Level>0</Level> > <Task>14336</Task> > <Opcode>0</Opcode> > <Keywords>0x8010000000000000</Keywords> > <TimeCreated SystemTime="2008-05-06T13:25:31.271Z" /> > <EventRecordID>8828341</EventRecordID> > <Correlation /> > <Execution ProcessID="612" ThreadID="1564" /> > <Channel>Security</Channel> > <Computer>BRCHDC01.brch.com</Computer> > <Security /> > </System> > <EventData> > <Data > Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data> > <Data Name="TargetUserName">MAGREL</Data> > <Data Name="Workstation">\\JCIFS18_143_B5</Data> > <Data Name="Status">0xc000006a</Data> > </EventData> > </Event> > Is it possible that Windows somehow lost it's machine name from the > updates and reverted back to it's default machine name until it was > rebooted? > > Charles > > "Meinolf Weber" wrote: > >> Hello Charles, >> >> Please post the complete event log, just press the 2 paper button in >> the right corner and paste it to the posting, so the complete error >> is here. This names will be no service from authentication or >> something else, this specifies machine names. >> >> Best regards >> >> Meinolf Weber >> Disclaimer: This posting is provided "AS IS" with no warranties, and >> confers >> no rights. >> ** Please do NOT email, only reply to Newsgroups >> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm >>> Below is the text from the event log: >>> >>> The domain controller attempted to validate the credentials for an >>> account. >>> >>> Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 >>> Logon Account: MAGREL >>> Source Workstation: \\JCIFS18_143_B5 >>> Error Code: 0xc000006a >>> Yes, we checked the DNS and the names were not in there. We also >>> have >>> a Cisco wireless network where we searched for the PC names but did >>> not find them. No...this is not a naming convention for our >>> network. >>> This is the first time we were unable to locate a host on our >>> network which is why we thought that these names may be legitimate >>> services attempting to authenticate since the user name "MAGREL" is >>> a legitimate user name used by services on some of our servers (the >>> ones that required a reboot from the Windows updates). Also, >>> remember that the issued went away after we rebooted the servers. >>> >>> Here are a few of the source names we found: >>> >>> JCIFS18_143_B5 >>> JCIFS18_15_5d >>> JCIFS18_145_ed >>> As you can see, all of the mystery names begin with JCIFS18. Is >>> this >>> the format used by Windows for services attempting to authenticat to >>> domain controllers? Please verify. From the above names, it >>> appears >>> that this is a naming convention used by some OS or service. Does >>> anyone recognise this naming convention? >>> Thanks. >>> >>> "Meinolf Weber" wrote: >>> >>>> Hello Charles, >>>> >>>> Please post the complete event viewer entry where these names are >>>> stated. >>>> Also did you check DNS for them? Is the naming according to your >>>> internal >>>> naming convention? >>>> And ofcourse you should reboot the servers after installing >>>> patches, >>>> so that >>>> also registry keys could update for example, otherwise some patches >>>> have >>>> no effect. >>>> Best regards >>>> Meinolf Weber >>>> Disclaimer: This posting is provided "AS IS" with no warranties, >>>> and >>>> confers >>>> no rights. >>>> ** Please do NOT email, only reply to Newsgroups >>>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm >>>>> We had a few Windows servers that had the last batch of Windows >>>>> Updates installed and were not rebooted (there was a box >>>>> indicating that a reboot was required on the desktop). We noticed >>>>> that a user account that is used on many services on these servers >>>>> was getting locked out on the domain controllers every couple of >>>>> minutes. We finally resolved the issue by rebooting the servers. >>>>> >>>>> What makes this odd is that the source of the authentication >>>>> request aws from JCIFS18_15_5D and JCIFS18_145_ED. These machines >>>>> do not exist on our network. We scanned our network and did not >>>>> find them. We did a NETSTAT -a and no host was found. >>>>> >>>>> My question is this: >>>>> >>>>> Does anyone know what JCIFS18_15_5D is? We're thinking that maybe >>>>> these are IDs for services that were attempting to authenticate to >>>>> the DCs. Could someone verify this? >>>>> >>>>> Thanks. >>>>>
Guest Charles Posted May 8, 2008 Posted May 8, 2008 Re: JCIFS18_15_5D The DC is not setup for remote access, but the other servers are setup to our vendor via a VPN through a Cisco firewall. I contacted the vendor and they were not attempting to authenticate using that account. In addition, the naming convention in question is not used on their network. I had them do a discovery scan on their network for the mystery PC names...but none were found (thinking that some one on their end was attempting to guess the password to hack into the servers). Again...this issue cleared up as soon as we rebooted the servers after the Windows updates...so it appears that the servers were in some funky state where they the DCs were not receiving the correct machine names. Charles "Meinolf Weber" wrote: > Hello Charles, > > You didn't mention before that it is 2008, the "button" option is from earlier > OS. No, the machine name will not go back to whatever it was before, was > the server named with this before? > > Is the server setup for remote access? So that someone from outside can connect > via VPN? > > The Error code C000006A means user name is correct but the password is wrong. > > Best regards > > Meinolf Weber > Disclaimer: This posting is provided "AS IS" with no warranties, and confers > no rights. > ** Please do NOT email, only reply to Newsgroups > ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > > > Our DCs are Server 2008...No idea what you mean by "the 2 paper button > > in the right corner" but hree are the details I was able to copy and > > paste: > > > > Log Name: Security > > Source: Microsoft-Windows-Security-Auditing > > Date: 5/6/2008 9:25:31 AM > > Event ID: 4776 > > Task Category: Credential Validation > > Level: Information > > Keywords: Audit Failure > > User: N/A > > Computer: BRCHDC01.brch.com > > Description: > > The domain controller attempted to validate the credentials for an > > account. > > Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 > > Logon Account: MAGREL > > Source Workstation: \\JCIFS18_143_B5 > > Error Code: 0xc000006a > > Event Xml: > > <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"> > > <System> > > <Provider Name="Microsoft-Windows-Security-Auditing" > > Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}" /> > > <EventID>4776</EventID> > > <Version>0</Version> > > <Level>0</Level> > > <Task>14336</Task> > > <Opcode>0</Opcode> > > <Keywords>0x8010000000000000</Keywords> > > <TimeCreated SystemTime="2008-05-06T13:25:31.271Z" /> > > <EventRecordID>8828341</EventRecordID> > > <Correlation /> > > <Execution ProcessID="612" ThreadID="1564" /> > > <Channel>Security</Channel> > > <Computer>BRCHDC01.brch.com</Computer> > > <Security /> > > </System> > > <EventData> > > <Data > > Name="PackageName">MICROSOFT_AUTHENTICATION_PACKAGE_V1_0</Data> > > <Data Name="TargetUserName">MAGREL</Data> > > <Data Name="Workstation">\\JCIFS18_143_B5</Data> > > <Data Name="Status">0xc000006a</Data> > > </EventData> > > </Event> > > Is it possible that Windows somehow lost it's machine name from the > > updates and reverted back to it's default machine name until it was > > rebooted? > > > > Charles > > > > "Meinolf Weber" wrote: > > > >> Hello Charles, > >> > >> Please post the complete event log, just press the 2 paper button in > >> the right corner and paste it to the posting, so the complete error > >> is here. This names will be no service from authentication or > >> something else, this specifies machine names. > >> > >> Best regards > >> > >> Meinolf Weber > >> Disclaimer: This posting is provided "AS IS" with no warranties, and > >> confers > >> no rights. > >> ** Please do NOT email, only reply to Newsgroups > >> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > >>> Below is the text from the event log: > >>> > >>> The domain controller attempted to validate the credentials for an > >>> account. > >>> > >>> Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 > >>> Logon Account: MAGREL > >>> Source Workstation: \\JCIFS18_143_B5 > >>> Error Code: 0xc000006a > >>> Yes, we checked the DNS and the names were not in there. We also > >>> have > >>> a Cisco wireless network where we searched for the PC names but did > >>> not find them. No...this is not a naming convention for our > >>> network. > >>> This is the first time we were unable to locate a host on our > >>> network which is why we thought that these names may be legitimate > >>> services attempting to authenticate since the user name "MAGREL" is > >>> a legitimate user name used by services on some of our servers (the > >>> ones that required a reboot from the Windows updates). Also, > >>> remember that the issued went away after we rebooted the servers. > >>> > >>> Here are a few of the source names we found: > >>> > >>> JCIFS18_143_B5 > >>> JCIFS18_15_5d > >>> JCIFS18_145_ed > >>> As you can see, all of the mystery names begin with JCIFS18. Is > >>> this > >>> the format used by Windows for services attempting to authenticat to > >>> domain controllers? Please verify. From the above names, it > >>> appears > >>> that this is a naming convention used by some OS or service. Does > >>> anyone recognise this naming convention? > >>> Thanks. > >>> > >>> "Meinolf Weber" wrote: > >>> > >>>> Hello Charles, > >>>> > >>>> Please post the complete event viewer entry where these names are > >>>> stated. > >>>> Also did you check DNS for them? Is the naming according to your > >>>> internal > >>>> naming convention? > >>>> And ofcourse you should reboot the servers after installing > >>>> patches, > >>>> so that > >>>> also registry keys could update for example, otherwise some patches > >>>> have > >>>> no effect. > >>>> Best regards > >>>> Meinolf Weber > >>>> Disclaimer: This posting is provided "AS IS" with no warranties, > >>>> and > >>>> confers > >>>> no rights. > >>>> ** Please do NOT email, only reply to Newsgroups > >>>> ** HELP us help YOU!!! http://www.blakjak.demon.co.uk/mul_crss.htm > >>>>> We had a few Windows servers that had the last batch of Windows > >>>>> Updates installed and were not rebooted (there was a box > >>>>> indicating that a reboot was required on the desktop). We noticed > >>>>> that a user account that is used on many services on these servers > >>>>> was getting locked out on the domain controllers every couple of > >>>>> minutes. We finally resolved the issue by rebooting the servers. > >>>>> > >>>>> What makes this odd is that the source of the authentication > >>>>> request aws from JCIFS18_15_5D and JCIFS18_145_ED. These machines > >>>>> do not exist on our network. We scanned our network and did not > >>>>> find them. We did a NETSTAT -a and no host was found. > >>>>> > >>>>> My question is this: > >>>>> > >>>>> Does anyone know what JCIFS18_15_5D is? We're thinking that maybe > >>>>> these are IDs for services that were attempting to authenticate to > >>>>> the DCs. Could someone verify this? > >>>>> > >>>>> Thanks. > >>>>> > > >
Recommended Posts