Re: Active Directory authentication
Prabhu Gurumurthy wrote: How about using login_radius feature by modifying login.conf to add a new radius profile and authenticate against a RADIUS server. You can compile freeradius and have rad_ldap plugin on the RADIUS server to authenticate against AD. Will that still require creating entries in /etc/passwd? How would it choose which login class the user's in?
Re: Active Directory authentication
Steve Shockley wrote: Prabhu Gurumurthy wrote: How about using login_radius feature by modifying login.conf to add a new radius profile and authenticate against a RADIUS server. You can compile freeradius and have rad_ldap plugin on the RADIUS server to authenticate against AD. Will that still require creating entries in /etc/passwd? How would it choose which login class the user's in? Yes, it will require adding entries on /etc/passwd, in other words you have to user useradd program, specifically -L option in useradd. userinfo username will give you the login class of a particular user. Remember you dont need to (re)set the password of the user if it is under radius profile. Prabhu
Re: Active Directory authentication
On Thursday 17 August 2006 00:39, Steve Shockley wrote: Okay, in that case login_radius offers no benefit to me over login_ldap (other than it's in base). Aside from the nsswitch patch posted on tech@, is there any auth method that does *not* require adding entries to /etc/passwd? Yes, NIS. --- Lars Hansson
Re: Active Directory authentication
That's not an easy scenario. Perhaps the simplest solution would work for you. You could implement a generic account on the firewall called say wifi-user. SSH into the filewall (not using Kerberos or anything) and log in using the shared password for wifi-user. The login shell could point to a script that would ask for an NTLM friendly username password, and the firewall could then attempt to read a file from \\someserver\someshare\file.txt using samba. If the contents of that file match a pre-known string say 'authenticated' then you know that the supplied username password are valid on the AD. If so, then proceed with authpf. Now set up read permissions on that file.txt, and give read permission to an AD group called wifi-users and add the users to the wifi-users group. It's not fancy, and I'm sure that some people on the list would distaste the inellegance of the solution, but it has worked in the past for me with a a squid-proxy setup. On 8/15/06, Steve Shockley [EMAIL PROTECTED] wrote: I'm researching setting up a wireless gateway using OpenBSD and authpf. We've got an existing Active Directory (2003) domain with about 5000 user accounts that I'd like to authenticate against. LDAP seemed like the obvious choice, but it appears I need to create local accounts to use login_ldap, and it'd be unwieldy to sync 5000 users. There's also a patch for nsswitch, but I'd rather not use a custom build if I don't have to. Kerberos also sounded like a good idea, but if I understand correctly, the clients would need a Kerberized ssh client, and they'd have to be able to access the KDC before logging in to the gateway. Is there a better way to do this?
Re: Active Directory authentication
Steve Shockley wrote: I'm researching setting up a wireless gateway using OpenBSD and authpf. We've got an existing Active Directory (2003) domain with about 5000 user accounts that I'd like to authenticate against. LDAP seemed like the obvious choice, but it appears I need to create local accounts to use login_ldap, and it'd be unwieldy to sync 5000 users. There's also a patch for nsswitch, but I'd rather not use a custom build if I don't have to. Kerberos also sounded like a good idea, but if I understand correctly, the clients would need a Kerberized ssh client, and they'd have to be able to access the KDC before logging in to the gateway. Is there a better way to do this? How about using login_radius feature by modifying login.conf to add a new radius profile and authenticate against a RADIUS server. You can compile freeradius and have rad_ldap plugin on the RADIUS server to authenticate against AD. Direct LDAP would have been my first choice but for time constraints. Prabhu --
Re: Active Directory authentication
2006/8/15, Steve Shockley [EMAIL PROTECTED]: I'm researching setting up a wireless gateway using OpenBSD and authpf. We've got an existing Active Directory (2003) domain with about 5000 user accounts that I'd like to authenticate against. LDAP seemed like the obvious choice, but it appears I need to create local accounts to use login_ldap, and it'd be unwieldy to sync 5000 users. There's also a patch for nsswitch, but I'd rather not use a custom build if I don't have to. Kerberos also sounded like a good idea, but if I understand correctly, the clients would need a Kerberized ssh client, and they'd have to be able to access the KDC before logging in to the gateway. LDAP integration seems to be one of the next goals of OpenBSD. What you can do now is to deploy Services for UNIX (SFU) on your Windows Server system and activate client NIS compatibilility and then setup your OpenBSD server for NIS. Windows Server R2 already has SFU built in. Not sure about the NIS service. Regards, -- Eduardo Alvarenga
Re: Active Directory authentication
From: [EMAIL PROTECTED] That's not an easy scenario. Perhaps the simplest solution would work for you. [snip login shell] [snip read file from UNC] [snip cartwheels and demonic contortions] 'A' for creativity, F for solution != simplest. If the users are logging into Windows workstations, they'll pull a Kerberos ticket from the KDC upon login. You can *in theory* use a Kerberized version of PuTTY (GSSAPI support), or any other Win32 SSH client that supports krb5/gssapi to facilitate your authpf against the OpenBSD box that hopefully should be able to participate in your ADS kerberos realm. That said, lots of shoulds and I haven't done it, but if it works it's far simpler and more maintainable... DS
Re: Active Directory authentication
On Tue, 2006-08-15 at 12:24 -0400, Steve Shockley wrote: Kerberos also sounded like a good idea, but if I understand correctly, the clients would need a Kerberized ssh client, and they'd have to be able to access the KDC before logging in to the gateway. having a kerberized SSH client isn't a must. If the client isn't setup to pass on credentials and you have the user class setup to use Kerberos on your gateway, then OpenSSH should just prompt the user for the password. Incidently, they'll be issued a ticket on the gateway. easiest way is to set your auth_defaults in /etc/login.conf: auth-defaults:auth=krb5-or-pwd,skey this is assuming you want to fallback on a password in your shadow file and then onto skey. Of course, make sure you have Kerberos set up properly in your /etc/kerberosV/krb5.conf file. later. ryanc -- Ryan Corder [EMAIL PROTECTED] Systems Engineer, NovaSys Health LLC. 501-219- ext. 646 [demime 1.01d removed an attachment of type application/pgp-signature which had a name of signature.asc]