Has anyone been able to get a single sign on with SuSE 9.2 in a win2k3 because it sure is giving me gray hair? I am trying to achieve authentication in a AD corporate infrastructure for testing linux machines for a project and I tell you all the other admins have run away from SuSE saying it is hopeless and user Fedora, I do not want to be in that boot but I have not been able to get it to work. I was following this link which the other admins used for Fedora and got Fedora to work no problem http://www.billboswellconsulting.com/addl_Linux_Info_authenticating_suse .html The company is going through a eval for using some Linux Desktops in their environment and I desperatly am trying to get this integration to work for me and SuSE :) but it is not woking out so far. I can get the pc to join the domain it shows up in the AD computers but authenticating against the domain is not working it is asking for username and password when trying to browse domain shares like the home shares, that does not happen on the Fedora machines. Any help from somone who has done such would be appreciated.
On Sun, 2005-03-06 at 09:00 -0500, Elijah Savage wrote:
Has anyone been able to get a single sign on with SuSE 9.2 in a win2k3 because it sure is giving me gray hair?
I have a coworker that just did this on SLES. I expect the same thing will work with 9.2. The trick, apparently, is that you need to use kerberos (for authorization) and winbind (for authentication). Now, I know next to nothing about this, but when my coworker got it all done, he sent me all the config files that got changed in the process. He used Yast to set it all up, and said it was fairly straightforward, once he Google'd the fact that you needed these two things. I'm going to attach the /etc/krb5.conf, edited to remove our domain names: =========================== [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/kdc.log kadmind = FILE:/var/log/kadmind.log [libdefaults] default_realm = SUB-DOMAIN.AD-DOMAIN.COM clockskew = 300 [realms] SUB-DOMAIN.AD-DOMAIN.COM = { kdc = server.sub-domain.ad-domain.com:88 default_domain = .sub-domain.ad-domain.com kpasswd_server = server.sub-domain.ad-domain.com:88 } [domain_realm] .sub-domain.ad-domain.com = SUB-DOMAIN.AD-DOMAIN.COM [appdefaults] pam = { ticket_lifetime = 1d renew_lifetime = 1d forwardable = true proxiable = false retain_after_close = false minimum_uid = 0 debug = false } ============================== /etc/pam.d/samba wound up like this: ============================== #%PAM-1.0 #auth required pam_unix.so #account required pam_unix.so auth required pam_nologin.so auth required pam_stack.so service=system-auth-winbind account required pam_stack.so service=system-auth-winbind session required pam_stack.so service=system-auth-winbind ============================== /etc/nsswitch.conf wound up like this: ============================== passwd: files winbind group: files winbind hosts: files dns networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files nis aliases: files ============================== The relevant parts of the [global] section of the smb.conf file: ============================== [global] workgroup = SUB-DOMAIN realm = sub-domain.ad-domain.com security = ADS encrypt passwords = yes idmap uid = 10000-20000 idmap gid = 10000-20000 winbind separator = + winbind use default domain = yes obey pam restrictions = yes template shell = /bin/bash winbind enum groups = yes winbind enum users = yes dns proxy = no ldap machine suffix = ou=Computers ldap suffix = dc=sub-domain,dc=ad-domain,dc=com password server = * wins server = <127.0.0.1> <-- REPLACE WITH THE IP FOR YOUR WINS wins support = no netbios name = <LOCAL MACHINE'S NAME> printer admin = @ntadmin, root, administrator =============================== /etc/pam.d/passwd: =============================== #%PAM-1.0 auth required pam_unix2.so nullok account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok #password required pam_make.so /var/yp session required pam_unix2.so =============================== /etc/pam.d/login: =============================== #%PAM-1.0 auth requisite pam_unix2.so nullok #set_secrpc auth required pam_securetty.so auth required pam_nologin.so #auth required pam_homecheck.so auth required pam_env.so auth required pam_mail.so account required pam_unix2.so password required pam_pwcheck.so nullok password required pam_unix2.so nullok use_first_pass use_authtok session required pam_unix2.so none # debug or trace session required pam_limits.so =============================== If you want to SSH into the box with Windows credentials, /etc/pam.d/sshd: =============================== #%PAM-1.0 auth required pam_unix2.so # set_secrpc auth required pam_nologin.so auth required pam_env.so account required pam_unix2.so account required pam_nologin.so password required pam_pwcheck.so password required pam_unix2.so use_first_pass use_authtok session required pam_unix2.so none # trace or debug session required pam_limits.so # Enable the following line to get resmgr support for # ssh sessions (see /usr/share/doc/packages/resmgr/README.SuSE) #session optional pam_resmgr.so fake_ttyname =============================== Again, most of this happens through Yast, as I understand it, but knowing what to actually PUT in the GUI boxes in, say, the Kerberos config panel might be a bit of a mystery. (Knowing that you need it to begin with was all news to me, anyway.) Same for Samba.
From my buddy's email: =============================== I suspect these were changed when I turned on the Kerberos Client from within yast2....
Here are a few interesting commands: 'kinit UserName@DomainName' Authenticates you against the domain. This allows you to see domain 'passwd' and 'group' files (Users & Groups). This is a part of Kerberos. 'klist' This lists Kerberos "tickets" - Authentication tokens This is a part of Kerberos. 'kdestroy Destroys Kerberos "tickets" You have to be authenticated to the domain for these command to show the domain counterparts: 'getent passwd' 'getent group' These spit out the combined list of users or groups, respectively, in the order they appear in nsswitch.conf. They do not show the Domain information if you aren't authenticated. There is a directory, '/data/test' that I used chgrp & chown on, with Domain Accounts/Groups: <machine>:~ # ls -l /data total 1 drwxr-xr-x 5 root root 104 Feb 22 13:37 . drwxr-xr-x 23 root root 568 Feb 22 07:17 .. drwxr-xr-x 2 admin<username> Domain Admins 48 Feb 22 13:37 test ==================================== I haven't actually tried this myself. (I was hoping, at some point, to create an LDAP server on my home network for single sign-on.) But I hope this helps you take over the world at your workplace. ;-) Regards, dk
participants (2)
-
David Krider
-
Elijah Savage