CFP3 in a domain environment [Resolved]

Hi Guys

Interested to hear those using CFP3 in a domain environment :). Anyone else having to wait ages (i.e 5-15 mins) to get to the desktop or is it just me? Loads to the desktop instantly using a local account but when logging onto the network >:( >:( >:(.

:slight_smile:

Edit: Btw, tried CFP2 and the same problem :'(.

I haven’t worked with a Windows Domain networked environment, so I’m kind of going on what I’ve read in the manuals and heard others describe as their experience.

To have that kind of delay sounds like an authentication time-out, where your machine is talking to the domain server, but possibly not hearing the server replies back to your machine. Have you checked the CFP logs for blocked ports? A domain environment is presumed “friendly” in that the client machines and the domain servers can both initiate LAN traffic and expect the other to reply. That seems likely to be what is breaking.

Graham, have you tried the old process of elimination? Disable one module (e.g. Defense+) at a time, and narrow down the options from there?

Unfortunately, disabling the modules (Firewall and/or Defense+) makes no difference, although I thought it would. From what I’ve read from other’s, this seems to be a common problem :(. Never used to be a problem and then one day… :'(. Have created global rules accessing both domain servers and workstations but nothing seems to make any difference.

:slight_smile:

Hmm…if disabling CFP itself doesn’t do it then it points to a driver issue (which is odd since it causes a delay rather than a crash). Anything in the Event Viewer?

It worked fine one day (using the default rules) and then it started taking ages to logon :cry: (no idea why ??? ). Maybe an update to CFP.

To have that kind of delay sounds like an authentication time-out, where your machine is talking to the domain server, but possibly not hearing the server replies back to your machine. Have you checked the CFP logs for blocked ports? A domain environment is presumed "friendly" in that the client machines and the domain servers can both initiate LAN traffic and expect the other to reply. That seems likely to be what is breaking.

It does eventually logon (after about 15 mins) but some drive mappings or servers can’t be accessed (very strange). Ports 137/138 are shown as being blocked but they were before when everything worked.

:slight_smile:

There was something about authentication (which I think may have been linked to CFP) but I would need to check again. Apart from that, nothing.

:slight_smile:

My workplace also uses a domain environment (not CFP3 related) with a similar symptom of unsually long logon time and it was to be a registry issue where some values referenced the incorrect URL. I’m just mumbling in my thoughts (:TNG).

If you believe it was due to the recent Update, why not try reverting back to the previous CFP version?

No idea which version it was :(. Even CFP2 doesn’t work now :'(. Anyhow, I would always want to use the latest version and hopefully fix or workaround any bugs. ■■■■ annoying this bug as I login when I arrive at work and then go off and make a coffee, XP still isn’t at the desktop ^_^.

:slight_smile:

Oh yeah. Sorry I forgot even 2.4 doesn’t work. Not sure if it’s feasible, but what about re-imaging?

Is there anything in the Windows events log (Run → eventvwr.msc) on your machine? And is there any kind of logging on the domain server that might be able to tell you what the server is encountering?

Re-imaged 3-4 times now but no difference :(. That said, I put CFP3 back on this morning and surprizingly, it loaded alot quicker (but still a little slow for my liking)

:slight_smile:

Just noticed this in the system log

“The Security System could not establish a secured connection with the server cifs/..ORG.UK. No authentication protocol was available.”

This is one of the servers that I cannot access.

Edit: Here is another error message:-

"The Security System detected an attempted downgrade attack for server cifs/..ORG.UK. The failure code from authentication protocol Kerberos was “There are currently no logon servers available to service the logon request.
(0xc000005e)”

:slight_smile:

Where those images created before the issue occured? If yes then I can’t really make any sense out of it.

Those log entries seem very relevant :smiley:

The image was created after a fresh install (after the problem). The only other thing I can think of is that something has changed on the server side (although I have been told it hasn’t).

Those log entries seem [b]very[/b] relevant :D

Hopefully they will give some kind of clue ;D. However, I’ve had to un-install CFP3 again as it was really stopping me from doing my work :'(. Still, if anyone knows what is going on, I would still be interested to know.

:slight_smile:

Some links related to your first event error:
http://www.eventid.net/display.asp?eventid=40961&eventno=1398&source=LsaSrv&phase=1

http://x220.win2ktest.com/forum/topic.asp?TOPIC_ID=8480

Second event error:
http://www.eventid.net/display.asp?eventid=40960&eventno=787&source=LsaSrv&phase=1

Hi Soyabeaner

Thanks for those links :). I’ve had a quick read from the first post but I can’t understand why this only occurs when CFP3 is installed. When CFP3 is un-installed, there are no problems what so ever and logon fast and are able to access all servers, shares, etc.

Personally, I think the problem lies with CFP3 rather than Windows (as much as I hate to say that).

:slight_smile:

Well, that’s a hint.

Kerberos is a sign-on authentication protocol. One of several that is supported in the Windows Domain networking. If the Kerberos protocol can’t work, it will go thru a time-out, and then the next authentication protocol will be tried in sequence. Kerberos is generally considered the most secure cross-platform authentication protocol available, so it is likely the very first one to be tried. The kerberos protocol has its own port numbers and client-server model, and it is more than likely these that are being blocked.

Checking the micrsoft.com web site, turns this How to force Kerberos to use TCP instead of UDP in Windows - Windows Server | Microsoft Learn mentioning UDP port 88.
This page http://technet2.microsoft.com/WindowsServer/en/library/b36b8071-3cc5-46fa-be13-280aa43f2fd21033.mspx?mfr=true
also references port 88 for both TCP and UDP for Kerberos use.

I would suggest then that CFP Global Rules allow inbound and outbound traffic for port 88 from your LAN servers (and only from your LAN servers, you don’t want somebody spoofing authentication bits).

That second microsoft.com link also has mention of a secure LDAP connection. LDAP uses port 389 (tcp and udp) to do its work. You might need to open up that port also.

Graham1,

Do you have any knowledge of packet sniffers ? like wireshark/tcpdump.
I have been troubleshooting this kind of problems lately also (nothing to do with CFP though).
I used this setup [Slow System] and my Sniffer Laptop connected to a HUB (Or switch with span port).

So you can see IF your system is communicating and with which server(s) maybe this could shed a light ?

Also, what’s you Systems OS and what’s the Domain environment, i guess w2000 or w2003 maybe w2008 ?
Because of the kerberos messages.

What’s peculiar is that you mentioned CFP 2.4 also causes the issue.