jhaar's questions

We have some voip phones that we want to integrate into our PEAP WiFi network, and I'm concerned about just creating a standard AD account and using that. If someone got hold of such long-term account credentials, they could then use them to log into hosts and access network resources

There are some policy/setting options for locking down local access, but they don't apply to network access. eg the "Log On To" option allows you to limit what machines an account can access, but a WiFi access point talking to a NPS/domain controller appears to use the host "" - ie it doesn't set that variable. That entire solution appears to only work against domain-member Windows computers - so wouldn't help if the user came in from a Unix/Mac system for instance (or PEAP of course)

This can be expanded to a more general question about how to use Active Directory for non-Windows authentication (eg LDAP). I haven't seen any real answers and so fear it may not be possible - but you've gotta ask right? :-)

We have our own CA which we've used for years to create hundreds of server certs and thousands of client certs. The CA cert itself is 1024bit and the certs it signed are 1024bit

Symantec has been sending out emails to us regarding this "change now to 2048bit certs" due to some relationship we have with external certs we use, which has now got me worried.

What will happen in Oct? Will OS vendors push out software updates that DISABLE their own ability to interact with 1024bit certs? If so, we have a serious problem as we'll have to replace thousands of certs ASAP

Replacing client certs and the CA cert itself for new 2048bit ones will be a manual nightmare. Originally that had to be done manually for all platforms other than Windows (thank you Microsoft for GPOs!), so does this change require us to also replace the CA, or would having that existing 1024bit CA cert signing 2048bit client/server certs be enough to "work around" the issue

We have a in-house developed WAF protecting our OWA (activesync) webserver, and part of its function requires long-lived Cookies on the "browsers". We're trying to get it to support iPhones via the "Mail" app (Safari works fine), but we've run into a problem

I was testing on an iPhone that was running 4.0 and it all worked fine. First time it connected, it was given a Cookie via Set-Cookie and every time it came back, it sent the cookie. However, after upgrading it to iOS 4.2.1 (latest release), it no long sends (or listens for) Cookies!

Moving the WAF down from HTTPS to HTTP allowed me to confirm with a sniffer. The Mail app first does a "POST", gets redirected to our cookie-generator page, is pushed a cookie and then redirected back - but it never sends the cookie. However, I do see this "X-Apple-Bad-Iphone-No-Cookie: True" header...

I've Googled for it - no luck. It sort of shouts out Apple has some kind of issue with Cookies?

Anyone got any ideas what's that about?

We're using openvpn to provide access back from XP to work. We use AD policies to ensure the XP firewall is up when off the domain and down when on the domain. With openvpn, you end up with a new network interface, and when you're off the domain and vpn back to work, XP goes "domain found but I'm also on a non-domain network, so firewall up".

However, I discovered we could use netsh to disable the firewall entirely on the openvpn interface:

echo firewall set opmode mode = DISABLE interface = "name of openvpn interface" | netsh

This is great: it means when our users are at home/hotels, their firewall is up - but remote access over the vpn works bi-directionally.

And then along came Win7 (let's pretend Vista doesn't exist - not too hard!). Gone is the concept of "domain" and "other", now it's "domain", "home/work" and "public" - and you cannot disable the firewall per interface. It's a lot more complicated than XP and as a side note I'm seeing lots of home users totally disabling Win7 firewalls due to it - grrr!

Anyway, my question is, how can I duplicate the functionality we have under XP? How can I script Win7 to totally disable firewall on the openvpn interface, but carry on as normal on the others? End result I'm after is that we (IS group, AV servers, vuln scanners) can access the box remotely when they're in hotels/at home/etc - just as if they were on the corporate LAN. I need a script as my experience with the GUI implies we'll otherwise need a 10page document of screensnaps for our helpdesk guys!

We have 40+ sites in 20+ countries. We use egress filtering and force most users through proxy servers via WPAD.

WPAD is great and works 99.9% for us. However, we have had a few cases where WPAD support issues has caused browsers (only MSIE - on rare occasions) or 3rd party apps (WebEX voip) to fail to work as they do not correctly figure out where the local proxy is - try direct - and fail.

So are there any other mechanisms for enabling enterprises with a plethora of egress points/proxies to be able to support all browsers (ie not just MSIE) and other web-clients - besides WPAD? As I mentioned, WPAD actually works 99.9% for us, but the trouble with that situation is that people only "see" the failures - and grizzling begins...

PS: no, "use DHCP" is not a different option. That is merely an alternative mechanism to deliver WPAD (the primary being DNS). Just thought I'd answer that before someone else does ;-)

Thanks

Jason