PiqueABoo

Just a few brain cells burnt out.. Finshed with various loose ends now and it definitely, definitely works for me. Both OWA and OMA happily connect to the exchange server with SSL. Hardest bit was figuring out how to get the relevant CA certificate onto various PDAs (three cheers for the MS mobile emulator 'technology preview').

Haven't finished everything with this yet, but so far method #3 does appear to work for me: The original /Exchange directory definitely requires SSL, the new IP-restricted 'ExchangeVDir' doesn't require SSL and syncs work.

When/if you sort out your network numbering, create a "Reverse lookup zone" for the network addresses in DNS.

Eeek.. I'm doing some of this stuff next month and thought there was a solution to OWA and OMA. So what's wrong with Method #3 on this page? http://www.petri.co.il/problems_with_forms_based_authentication_and_ssl_in_activesync.htm

I'm no expert etc., but I'm really struggling to see what the criminal case would be e.g. no one would be bypassing a technogical protection mechanism... ...and I'm struggling to see what the civil case might be e.g. I don't see how MS would be able to claim credible damages if you replace a graphic. I guess we need some case law, but I just can't see MS pursuing anyone for this kind of thing.

?!? Uh ?!? All IP addresses beginning with 128.2 belong to Carnegie Mellon University aka CMU. Those strange DNS cache entries of yours are a direct result of using someone else's addresses. You need to find out how that happened and fix it ASAP i.e. change the IP numbering of your network to a range you "own".

Ok I miss-typed that "mapings" comment but basically if I do this: > nslookup 128.2.2.142 Then I get all sorts of stuff in my cache which is *perfectly normal*: --forward zone edu.net NS ac-ddns2.net.cmu.edu. NS ddns-a100.net.cmu.edu. NS ac-ddns1.net.cmu.edu. A AC-DDNS1 128.2.1.15 A AC-DDNS2 128.2.1.16 A DDNS-A100 128.2.1.16 A t-ns1 128.2.4.14 A t-ns2-sec 128.237.148.6 --reverse zone 128.2.2 NS ac-ddns2.net.cmu.edu. NS ddns-a100.net.cmu.edu. NS ac-ddns1.net.cmu.edu. PTR 142 gruel-2-142.ppp.andrew.cmu.edu. The only question is why would something on my network be wanting to look up that IP address.. or alternatively why would it want to look up gruel-2-142.ppp.andrew.cmu.edu? Apart from a few more gruels, does your cache have anything significantly different or not? In particular do any of the IP addresses in the cache belong to your network? Meanwhile 2.142 should not be the network part of your address (i.e. the first two octets) because whois says 2.0.0.0/8 is reserved. So I think you're saying it's the last two octets that match e.g. x.x.2.142 and that doesn't prove anything. I also don't get is what you mean with "scans" and "clients were reporting their DNS names". It's typically the scanner itself that looks up DNS names to fit IP addresses, so what were you running and where from? Could it be buggy? Is there any reason some 128.2.x.x addresses might be floating about on your network. Have you seen any say with Ethereal? Could a small typo on some machine/device result in that? Rootkit Revealer is good.. I'd have run that on all the DCs.. probably followed by Autoruns (with don't display signed MS stuff turned on to reduce the clutter)... and then some AV scanner.. provided everything looked fine I'd then change all the admin passwords. Then I'd scour the event logs for anything unusual concerning DNS & DHCP. Then I'd find a hub, connect it between your network and router, then connect a laptop with Ethereal on it to see if anything on my network is trying to talk to 128.2.x.x addresses (obviously then checking any workstation that are). NMap isn't so useful in this scenario unless you scan the full 65K+ ports on each machine.

VLAN it to where? You're going to have to make a gateway for that VLAN somewhere. Simplest would be to make that a spare LAN interface on your WAN router and set some ACLs, but if you don't have a spare i/f then a linux NAT box would be fine. Well unless your switches also route & implement layer-3 ACLs.

Agreed. It's difficult to judge from a distance, but if something sufficiently strange happened on mine I'd take the phone off the hook, pull the WAN link, verify the servers were free of any active malware, change the admin password(s) and then set about trying to figure out what happened. In this particular case, the right details aren't there so I can't judge what going on with the DNS cache, scans and clients reporting names. Could be a red herring coz if you've got an authoritative reverse zone then I don't think your IP-to name mappings will not appear in the cache. Forwarders & scopes both disappering is less easy to dismiss i.e. the most likely reason is because someone has access and removed them.

I've done security forever and TBH I can't figure out from your post whether your network is seriously compromised or just broken. However if Geoff is right and you do follow his advice, I recommend step 4 *first* otherwise you might find it gets compromised all over again before you've finished reimaging.

No, but I can see the potential for conflicts with rootkit-like software. Definitely worth pulling PCE off a machine to see if the problem goes away.

I said it "raises the bar bit" which is not poor practice compared with leaving the bar on the floor. The approaches are not mutually exclusive, but yes properly configured VLANs, ACLs et al are much, much better. If the equipment supports the latter then I'd seriously consider the pros and cons of implementing that stuff. Meanwhile, IP devices only need a gateway if they need to talk to the outside world and vice versa. Printers, switches, APs and the like do not need to talk to the outside world. And there is no conventional routing in this scenario - IP comms between two 192 devices relies on exactly the same mechanism (ARP) as IP comms between 172 devices. -- DHCP redundancy *is* complex. The 80/20 rule relies on the 20 server being reliably slower to respond to requests (it's supposed to be on a remote subnet). The scope split is better based on making an educated guess for "what percentage of your machines are likely to a) have been offline for the lease duration, and b) will get switched on while their local DHCP server is down?". If you've only got one subnet, I'd consider setting up a second service with a few spare addresses but disabling it until needed. You could run both concurrently with a 50/50 split but watch our for bias i.e. significantly more leases being assigned from one server than the other.

True.. if I wanted to do something naughty and knew how I typed was analyzed, I'd deliberately alter my typing style e.g. just use little fingers. It would only really works if a logon depends on both the correct password and how it is typed.. and although you'd then have more ammunition to prove the user's identity, it's definitely not absolute.

Don't know what that or any other one does but if I'd built an app centred on key-logging: A user's typing style is a biometric that can be used for authentication. i.e. it has a sufficiently unique signature.

Well I think we'll just have to agree to disagree then... To me it's useful to have the logical separation between a) the Windows domain boxes, and b) all those other devices with their various (and variously secure) services that users have no need to access. Maybe I've got a warped mind, but I think a network "overlay" like that is a simple concept and trivial to configure/maintain.. just a minute of additional work when you add servers to handle print queues or setup a network admin workstation. And I don't think it's paranoid, but I'm aware of various exploits and one school in particilar that spent a lot of time tearing their hair out over some printer mischief this would have stopped dead. A better p-word word is prudent... it doesn't cost much and might save you a lot of hassle. It also conserves real IP addresses (assuming you use those for your workstations).

I'd pull the plug. Graceful logoff & shutdown will modify the state of the (file) system. It might even be set to secure wipe history, page files and the like. And I can't see how you can do *anything* prior to that without altering the state of the system and being open to claims of tampering etc. I suppose it would be a bit of a downer if the owner/user happened to have their plausibly deniable virtual disk open at that point, but.. Anyway what's the answer (why and why not the others)?

It is not a pants setup (or at least it wasn't). It's a perfectly adequate setup designed to raise the bar a little to prevent workstations on your LAN from messing with resources they don't need to access. Comments about routing are red herrings. Supernetting and subnetting has been around and perfectly valid for a long time i.e. 255.255.252.* is perfectly fine here, regardless of what some calculator says. Strictly classful networking went by the way ages ago in order to alleviate the alleged "world running out of IP addresses" problem. Again DHCP and DDNS is mostly for random workstations, whereas everything else usually requires a static address. If you do have a devices like that.. and you always do.. it's a good idea to manually add DNS entries for them. I wouldn't bother with DHCP reservations (but the static address must be in an excluded-for-lease range). If it were my network I'd likely change the new stuff you put in from 172 to 192 addresses to be consistent with the others. If I did have to talk to my switches and printers from somewhere besides the server it would likely only be one specific admin machine (probably a troubleshooting laptop) and I would give that static address in both the 172 and 192 ranges. Regardless I can always remote desktop to the server.

It's a perfectly reasonable scenario, I'd have added new printers & switches to the 192.168 range. To "see" them I'd add them into DNS same way I'd add any device with any static IP that doesn't do DDNS. STP is supposed to work at layer-2 (MAC Address). IP is layer-3 and should be irrelevent to STP. I can't quite decode what you mean by "latency in resolution".. is that figuring out what IP addresses go with the MACs? Or is it also trying to get DNS names? Whatever, I suspect the 'performance' issue only affects Ethereal.

The tech time argument is definitely the compelling one. Said it before on usenet (to some slight hissing): I reckon it would take me 12 months to replicate all the useful bits from scratch. Obviously that's not the same amount of time it would take to get something more pragmatic up and running. The thing that bothers me about RM is the overall quality. After all this time I'd have thought it would all be nailed down (code/script/driver management/UIs et al), but I feel like I'm dealing with an ad-hoc collection of beta code.

..b-b-b-but.. ISA 2000 has a proxy/cache. What do you want to do with Squid that you can't already do with ISA?

Been trying this.. & trying that ..& googling.. & trying something else ..& by and by.. If you want Boothbox (boothbox.sourceforge.net) to definitely, definitely have a UK keyboard then one way to do that in your remastering enviroment is to go modify where the language vars are set in: /etc/init.d/knoppix-autoconfig

Glanced at so far: KioskCD - easy to config (util writes config directly to ISO), but I want to zap the Firefox links bar and haven't figured out if you can. Had to tell it skip DNS test to work. BoothBox - favourite UI (full screen Firefox) but it looks like I'll need to fiddle quite a lot for UK keyboard etc. ThinStation - used one of the online ISO build sites which is nice and provides a Firefox Kiosk config. Having problems getting decent screen size (testing under VMWare).

A primary school is upgrading a suite full of old boxes (550MHz, 64MB, CDs) and was wondering whether they might still be useful for something. Haven't looked inside or tried it, but I've been wondering whether: a) It might be possible to move some RAM around to make some 128MB machines. b) They would run something low maintenance e.g. a LiveCD (or HD installed) WWW kiosk. Bad idea? If not, has anyone done this and what did you use?

> That's fine, unless you have an on-site proxy server! They likely assume you have ISA (which makes most sense to me when it is your gateway).