|
Bugzilla – Full Text Bug Listing |
| Summary: | pam winbind settings are only set if we join a windows domain using Yast as a client | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE 12.2 | Reporter: | Forgotten User Ku1lZ_yaEZ <forgotten_Ku1lZ_yaEZ> |
| Component: | Samba | Assignee: | The 'Opening Windows to a Wider World' guys <samba-maintainers> |
| Status: | VERIFIED UPSTREAM | QA Contact: | The 'Opening Windows to a Wider World' guys <samba-maintainers> |
| Severity: | Enhancement | ||
| Priority: | P5 - None | CC: | ddiss, jsuchome, samba-maintainers |
| Version: | RC 2 | ||
| Target Milestone: | --- | ||
| Hardware: | i586 | ||
| OS: | openSUSE 12.2 | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | 770390 | ||
| Bug Blocks: | |||
|
Description
Forgotten User Ku1lZ_yaEZ
2012-08-20 14:36:53 UTC
Lars suggested: Jiří Suchomel jsuchome@suse.com for this. Hope that's OK. Thanks. Have you tried using YaST samba client (called Window Domain Membership)? Yes, but this will only work for joining a client to an already existing domain. In this case the openSUSE box is itself already the domain controller. Maybe we could add something in the dialogue to cover this? The settings are quite easy but I think with Samba4 just around the corner we should add this to Yast: Here are the proposed pam settings from the Samba guys which don't work with 12.1 nor 12.2: /etc/pam.d/common-auth Add this line before pam_unix.so: auth sufficient pam_winbind.so Also add the option use_first_pass to the pam_unix.so line /etc/pam.d/common-account Add this line before pam_unix.so: account sufficient pam_winbind.so /etc/pam.d/common-session Add these lines before any other session line: session required pam_winbind.so Thanks YaST does not edit PAM files directly, it uses pam-config. Does pam-config support the situation above? Hi winbind isn't mentioned in: pam-config --help pam-config certainly can manage winbing (see man pam-config), as YaST is already using it. The question is, if the details from comment 3 are supported. The config in comment #3 is broken, it will lock out everybody including root if there is a problem with the network not comming up correct. Lynn, why does pam-config -a --winbind not work for you on 12.1 and 12.2? OK I'll use that. I just thought it would be nice for tus to have something like a tick the box solution like pam-auth-config in Ubuntu. If 'pam-config -a --winbind' works for you, than should YaST module. The checkbox "Use SMB Information for Linux Authentication" is exactly indicating usage of this pam-config call. Hi Jiri I am not trying to join an openSUSE client to an existing domain. I am trying to get winbind authentication working via Samba4. I cannot chack the box "Use SMB Information for Linux Authentication" in windows Domain Membership because I am not joining a Linux client. I am already the 'windows' domain joined to myself simply by installing Samba4. We do not have a Yast module to do this. If we are already the DC we need some way of activating winbind authentication. With AD Domain Controller on Linux just around the corner (4th Sept. I think is the RC1 for Samba4) I really do think we should address this. Ubuntu have it: pam-auth-update and simply choose your flavour. We don't. Thanks, L (In reply to comment #10) > Ubuntu have it: pam-auth-update and simply choose your flavour. We don't. Sorry, but we have exactly the same: pam-config -a --winbind is the exact equivalent to pam-auth-update from Ubuntu for this case. Only that the Ubuntu clone is much more restricted (as it can only copy PAM config files and is not able to generate them itself, so I don't understand why they had to invent the wheel again and not use the better original ;) ). So, Lars, would it make sense to allow "Use SMB Information for Linux Authentication" checkbox even without joining a domain? (In reply to comment #12) > So, Lars, would it make sense to allow "Use SMB Information for Linux > Authentication" checkbox even without joining a domain? This behaviour would be very much specific to a Samba 4 AD DC setup. This bug should be made a duplicate (or child feature req) of bnc#770390 IMO. (In reply to comment #11) > (In reply to comment #10) > > Ubuntu have it: pam-auth-update and simply choose your flavour. We don't. > > Sorry, but we have exactly the same: > > pam-config -a --winbind is the exact equivalent to pam-auth-update from Ubuntu > for this case. > > Only that the Ubuntu clone is much more restricted (as it can only copy PAM > config files and is not able to generate them itself, so I don't understand why > they had to invent the wheel again and not use the better original ;) ). Yes, but it means typing nonsense at the command line. I can do it, but my parents and colleagues certainly can't! With Ubuntu I get a list to choose from. Sorry, but that's what people need. (In reply to comment #13) > (In reply to comment #12) > > So, Lars, would it make sense to allow "Use SMB Information for Linux > > Authentication" checkbox even without joining a domain? > > This behaviour would be very much specific to a Samba 4 AD DC setup. This bug > should be made a duplicate (or child feature req) of bnc#770390 IMO. How about just put an extra option for 'I'm already the DC, let me use pam winbind anyway' L x (In reply to comment #13) > (In reply to comment #12) > > So, Lars, would it make sense to allow "Use SMB Information for Linux > > Authentication" checkbox even without joining a domain? > > This behaviour would be very much specific to a Samba 4 AD DC setup. This bug > should be made a duplicate (or child feature req) of bnc#770390 IMO. 770390 refers to DNS, not PAM. We have to ensure to keep this dialog simple and straight. The main purpose is to join a domain and while we join this is a question of one extra click. @Jiří: Do you see an easy and also user friendly way to add the required extra feature to the YaST Windows Domain Membership module without making the tool unfriendly from the usability point of view? Well, the required extra feature is saving the pam config, but not joining. We have to do less than we do now. So, we may 1. offer (universal) checkbox with "Do not join" label or something 2. detect user's configuration state (Samba 4) and a) ignore the join automatically (or based on some technical conditions) b) explicitely ask user (via popup) if he also wants to join So, what would you prefer? To me, it looks like some variant to option 2. What should I do to properly detect user's situation? (In reply to comment #18) > Well, the required extra feature is saving the pam config, but not joining. We > have to do less than we do now. > > So, we may > > 1. offer (universal) checkbox with "Do not join" label or something > 2. detect user's configuration state (Samba 4) and > > a) ignore the join automatically (or based on some technical conditions) > b) explicitely ask user (via popup) if he also wants to join > > > So, what would you prefer? To me, it looks like some variant to option 2. What > should I do to properly detect user's situation? Indeed, option 2 would be preferred. Ideally the user could select "AD Domain Controller" on the YaST Samba Server "Identity" tab, the resulting setup wizard would take the user through provisioning, DNS server setup, and later PAM configuration. (In reply to comment #19) > Indeed, option 2 would be preferred. Ideally the user could select "AD Domain > Controller" on the YaST Samba Server "Identity" tab, the resulting setup wizard > would take the user through provisioning, DNS server setup, and later PAM > configuration. Well, but that is a complex solution for bug 770390, here. I thought we want to have a simple one for this bug, which would fit to YaST Samba Client module... Option 2 a from comment #18 is what I suggest to do. While it should be possible to the user to overwrite the suggestion. This plus Dave's comment #19 provides the required information. (In reply to comment #20) > (In reply to comment #19) > > > Indeed, option 2 would be preferred. Ideally the user could select "AD Domain > > Controller" on the YaST Samba Server "Identity" tab, the resulting setup wizard > > would take the user through provisioning, DNS server setup, and later PAM > > configuration. > > Well, but that is a complex solution for bug 770390, here. Yes. > I thought we want to have a simple one for this bug, which would fit to YaST > Samba Client module... IMO proceeding with the implementation for 2a from comment#18 wouldn't make much sense prior to having other AD Domain Controller components (most importantly Samba) configurable via YaST. (In reply to comment #19) > Indeed, option 2 would be preferred. Ideally the user could select "AD Domain > Controller" on the YaST Samba Server "Identity" tab, the resulting setup wizard > would take the user through provisioning, DNS server setup, and later PAM > configuration. Now, neither this one nore bug 770390 describes what needs to be done for such Samba Server update. Do you have a list of requirements anywhere? Preferably a feature request? (In reply to comment #23) > (In reply to comment #19) > > > Indeed, option 2 would be preferred. Ideally the user could select "AD Domain > > Controller" on the YaST Samba Server "Identity" tab, the resulting setup wizard > > would take the user through provisioning, DNS server setup, and later PAM > > configuration. > > Now, neither this one nore bug 770390 describes what needs to be done for such > Samba Server update. > > Do you have a list of requirements anywhere? Preferably a feature request? Not yet, Samba4 is currently still in beta, hence the AD DC setup process changes regularly. An RC should be coming next month, which would be a good point to finalize the UI and back-end configuration requirements. Moving to samba team: please clarify the requirements for YaST, if they are any. There are no requirements for YaST at the moment. The Samba 4 AD DC setup reply on the Heimdal Kerberos implementation, while SUSE uses the shipped system-wide MIT Kerberos. The Samba 4 AD DC setup relies ... |