JCIFS18_15_5D

  • Thread starter Thread starter Charles
  • Start date Start date
C

Charles

Guest
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.
 
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.
>
 
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.
> >

>
>
>
 
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.
>>>
 
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.
> >>>

>
>
>
 
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.
>>>>>
 
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.
> >>>>>

>
>
>
 
Back
Top