Guest User!

You are not Sophos Staff.

Thread Info
  • State Not Answered
  • Replies 2 replies
  • Subscribers 0 subscribers
  • Views 616 views
  • Users 0 members are here
Options
Suggested

[7.386] Overall Comments, 1 Request

grgcombs
Overall, I'm very pleased with this beta series.  So far I have yet to find any trouble, however it should be noted this is running inside my home with more or less casual traffic.

The interface feels much snappier.  I don't get the long login loading times that I used to, even with 7.3. (My browser is the latest Apple Safari).  Things have been rearranged and functions clarified, so that's a big plus, too. Additionally, the new features and enhancements (at least the ones I can use in my home infrastructure) seem to work quite well.

I dare say it at least feels production-ready *to me*, certainly more so than other beta series in the past.

My one request, which I mention in passing because we have a workaround, is remote verification for PPTP and L2PT (or is it SSH?) vpn users ... right now we have to have users verified against the firewall's local password database.  For any other action we get the opportunity to verify against a remote database.  Personally, I use Apple's Open Directory that comes with Mac OS X Server, and it seems to work quite well with Astaro, aside from this minor/known issue.
Parents
  • 0
    My one request, which I mention in passing because we have a workaround, is remote verification for PPTP and L2PT (or is it SSH?) vpn users ... 


    Thanks for the feedback!

    The limiting factor for use of authentication backends with PPTP and L2TP-over-IPsec is actually protocol inherent. Both make use of PPP protocols to do username/password authentication. Currently we only support the challenge response protocol MSCHAPv2, which secures the transferred password by encrypting it at the client and thus makes it useless for verification backends. The only one that can handle challenge/response based protocols itself is RADIUS. That's why you can select RADIUS as the only alternative to local authentication with PPTP/L2TP.

    I don't know MacOS X Server, but chances are good that it comes with a RADIUS frontend for it's authentication database (Windows Server has it for a while now). If so, you could authenticate against the MacOS RADIUS which in turn would look up the credentials in the directory.

    There are several ideas on how to get past some of the existing limitations, but none of them has made it into the product so far. So check back when new releases are announced, this is something that will be worked on some day.
  • 0 in reply to d12fk
    This makes sense.  OSX Server has Radius, but it's an odd implementation ... it seems it is geared more towards authentication specifically from/for their Airport wireless access points, rather than general (wired) network authentication.  Moreover, when you activate it on the server, it seems it requires implementation on your access points, forcing an overwrite of your existing settings.

    So, in short, I don't think I'll be turning Radius on, at least until they rethink their implementation. [8-)]

    Thanks for the update and info on this, though.

    Greg

    Thanks for the feedback!

    The limiting factor for use of authentication backends with PPTP and L2TP-over-IPsec is actually protocol inherent. Both make use of PPP protocols to do username/password authentication. Currently we only support the challenge response protocol MSCHAPv2, which secures the transferred password by encrypting it at the client and thus makes it useless for verification backends. The only one that can handle challenge/response based protocols itself is RADIUS. That's why you can select RADIUS as the only alternative to local authentication with PPTP/L2TP.

    I don't know MacOS X Server, but chances are good that it comes with a RADIUS frontend for it's authentication database (Windows Server has it for a while now). If so, you could authenticate against the MacOS RADIUS which in turn would look up the credentials in the directory.

    There are several ideas on how to get past some of the existing limitations, but none of them has made it into the product so far. So check back when new releases are announced, this is something that will be worked on some day.
Reply
  • 0 in reply to d12fk
    This makes sense.  OSX Server has Radius, but it's an odd implementation ... it seems it is geared more towards authentication specifically from/for their Airport wireless access points, rather than general (wired) network authentication.  Moreover, when you activate it on the server, it seems it requires implementation on your access points, forcing an overwrite of your existing settings.

    So, in short, I don't think I'll be turning Radius on, at least until they rethink their implementation. [8-)]

    Thanks for the update and info on this, though.

    Greg

    Thanks for the feedback!

    The limiting factor for use of authentication backends with PPTP and L2TP-over-IPsec is actually protocol inherent. Both make use of PPP protocols to do username/password authentication. Currently we only support the challenge response protocol MSCHAPv2, which secures the transferred password by encrypting it at the client and thus makes it useless for verification backends. The only one that can handle challenge/response based protocols itself is RADIUS. That's why you can select RADIUS as the only alternative to local authentication with PPTP/L2TP.

    I don't know MacOS X Server, but chances are good that it comes with a RADIUS frontend for it's authentication database (Windows Server has it for a while now). If so, you could authenticate against the MacOS RADIUS which in turn would look up the credentials in the directory.

    There are several ideas on how to get past some of the existing limitations, but none of them has made it into the product so far. So check back when new releases are announced, this is something that will be worked on some day.
Children
No Data