Drakauth has a number of configuration problems that occur when Kerberos 5 and OpenLDAP are used for authentication. 1. Kerberos 5 configuration files are malformed, resulting in the computer being unable to authenticate. It throws an error about a Syntax error in the configuration. This is mostly due to white space in the file. But there is a syntax error where a line about domain location starts with an "=" sign with no subject. 2. When using LDAP, Drakauth only sets the Base DN Config, an not any of the other locations of the other sub containers of the People, and Group configs. The default out of passwd is ou=People, the default for group is ou=Group, but Drakauth sets everything to the base DC. 3. Sudoers should have its own automatic setup. Mageia has the ability to setup LDAP based sudoers, So 4. Drakauth improperly usees tls_checkpeer if SSL or TLS is enabled. It sets TLS Checkpeer but doesn't provide a way to get the Certificate from the server correctly. It also doesn't provide a way to turn TLS Check peer off resulting in the inability to log in. 5. Drak auth does not configure userdrake to enumerate and modify LDAP accounts. userdrake DOES have this ability if and only if libuser is configured to do so. (On the server end, smbk5pwd has to be setup right so that when userdrake creates the POSIX account, and the Samba account, the Kerberos Principal is created as well.
Another thing. userdrake can configure local users, or LDAP users, but not both at once. It has no support for configuring Kerberos related properties.
CC: (none) => luigiwalserAssignee: bugsquad => thierry.vignaud
Hello, Your first issue should be fixed in trunk now, thanks for the report, Iâll try to see what I can do for the other items Regards,
CC: (none) => shikamaru
Okay, I have found that migrating from nss_ldap to nss-pam-ldapd resolves the deadlock issues. So Mageia should install that instead. (nss_ldap is deprecated.)
In this file on your system: /usr/lib/libDrakX/authentication.pm Also in SVN here: http://svnweb.mageia.org/soft/drakx/trunk/perl-install/authentication.pm?revision=7897&view=markup You can find the code that controls this. Patches are welcome! For #2, it depends on your LDAP setup, but I believe there's an "advanced" option in drakauth that lets you set those. It is now installing nss-pam-ldapd, but it doesn't configure it correctly (or, at all). See more detail in Bug 10005.
CC: (none) => derekjennDepends on: (none) => 10005
Zombie, can you give some more feedback on this? We have a developer actively looking into fixing these things now. For #1, in Comment 2, Rémy said it was fixed in trunk, which hopefully should have made it to Cauldron by now. Can you confirm it's fixed? For #2, can you confirm that use of the "advanced" option is sufficient? For #3, I have sudoers using an LDAP group at work, but I can't think of a way to do that automatically and generically, we use a specific group that we set up. Do you have some idea of how the tool could actually do that? For #4, is there some standard way of downloading a certificate from the server that the tool could use? Or do we just need to provide the ability to add one from a file? I guess adding a checkbox to the GUI allowing to disable that option should be done though. For #5, Can you give some details on how to configure libuser to do this?
#5. Install libuser-ldap and then: Mofify /etc/libuser.conf create_modules = ldap [ldap] # Setting these is always necessary. server = <fqdn to Server> basedn = dc=example,dc=com bindtype = simple userBranch = ou=People groupBranch = ou=Group # Set only if your administrative user uses simple bind operations to # connect to the server. binddn = cn=Manager,dc=example,dc=com password = <your password> Set up right, libuser will enumerate ldap accounts and so will userdrake. For #4, set this. TLS_REQCERT allow TLS_CHECKPEER no For #2, yes, that would be fine. Number 3 is kind of tricky. I use a group as well for that purpose, SUDOERS_BASE ou=sudoers,ou=System,dc=example,dc=com SUDOERS_DEBUG 0 ldap_version 3 SSL on The Group is listed there.
Thanks Zombie. OK, so #1 and #2 should be OK now. For #3, that's pretty site-specific. I don't actually know where the SUDOERS_BASE thing would go, as it's not documented in the man pages for /etc/nslcd.conf nor /etc/openldap/ldap.conf. At work we also use a group that comes from LDAP for sudoers, but it's a unix group, not an LDAP one (although there's probably an LDAP group that underlies it). Allowing to specify this through the tool would be nice, but not strictly necessary. For #4, I guess the right way to go would be to allow the user to import a cacert from a file. If they do, save it in /etc/pki/tls/certs and then run c_rehash, and also set tls_cacertfile to the path to the saved cacert file. If they don't import a cacert, just set tls_reqcert to allow. tls_checkpeer is deprecated and shouldn't be set. TLS_REQCERT in all caps is how it's specified in /etc/openldap/ldap.conf, but I don't think nss-pam-ldapd uses that. Or maybe the easier thing would be to just have the tool set tls_reqcert to allow, and let them change it by hand if they actually have a cacert and know what they're doing. For #5, configuring libuser as Zombie described above seems sensible. You would want to make sure that 600 perms are set on /etc/nslcd.conf and /etc/libuser.conf as they both contain a password.
SUDOERS_BASE is in ldap.conf and I really wish there was a way of doing sudoers by Kerberos rather than straight LDAP. Both libuser-ldap and sudo want Simple Binds to function properly, and I don't know if SASL binds would help matters. Keep in mind that future Implementations of this will be "Samba 4" as if you are running Samba 4, Samba 4 (Active Directory) Is just a different configuration of OpenLDAP and Heimdal Kerberos. Both libuser-ldap you only want running on Domain Controllers. But Sudoers should really be Kerberos, not LDAP.
I imagine it's better to use a unix group for sudoers then, that way it's not tied to a particular authentication method. If the libuser-ldap configuration should only be on the server (that makes sense), then drakwizard would be the correct place to do it, not drakauth. So to review, the only things to do for drakauth: Relating to #3, maybe allow to specify a unix group to use for sudoers. Relating to #4, set tls_reqcert to allow instead of demand by default, plus maybe allow to import a cacert file and set it to demand then.
I disagree about sudoers not being in ldap. (while it needs Kerberos.) LDAP uses sudo.schema to determine what privileges sudoers have.
(In reply to Zombie Ryushu from comment #10) > I disagree about sudoers not being in ldap. (while it needs Kerberos.) LDAP > uses sudo.schema to determine what privileges sudoers have. What?
(In reply to David Walser from comment #11) > (In reply to Zombie Ryushu from comment #10) > > I disagree about sudoers not being in ldap. (while it needs Kerberos.) LDAP > > uses sudo.schema to determine what privileges sudoers have. > > What? The point of sudo.schema in OpenLDAP is that not only does it determine sudoers in a Domain level, it allows the unique privileges assigned to said sudoers in LDAP at the domain level. So if you are in a group that only sudo urpmi and nothing else, for example, you will be able to sudo urpmi on every machine in the Domain, with the exact same priviliges. It uses a bit of a wonky syntax, but you can basically do everything you can do with /etc/sudoers only on a Domain Level. I just wish it validated that by Kerberos. LDAP is for Authorization, not Authentication. Kerberos is for Authentication.
I wonder why SUDOERS_BASE isn't documented for ldap.conf. So what you're saying is that doesn't just give people in that group ALL sudo privleges, but it's more fine grained and you can control what access they have in the LDAP server. I suppose it might be nice to allow adding that as an option, but nothing else drakauth does now requires editing ldap.conf.
Distinguished Name: cn=%Administrators,ou=sudoers,ou=System,dc=example,dc=com ObjectClasses sudoRole top Attributes cn %Administrators description Administrators Sudo Permissions. sudoCommand ALL sudoHost ALL sudoUser %Administrators Here is a Sample Sudo definition in LDAP It defines what host, what command and what user (% means Group) can use sudo. SUDOERS_BASE is only used by sudo. So you have to look at sudo's documentation. This isn't bad except: It doesn't check Kerberos. The next thing sudo should ask is: Do you have a Valid Kerberos ticket to go with that LDAP entry.
All you need to do is point SUDOERS_BASE at the right DN Suffix and you are fine. So what Drakauth should do is offer the option: Use LDAP for sudoers. And if checked, offer a path to the SUDOERS_BASE/
This message is a reminder that Mageia 2 is nearing its end of life. Approximately one month from now Mageia will stop maintaining and issuing updates for Mageia 2. At that time this bug will be closed as WONTFIX (EOL) if it remains open with a Mageia 'version' of '2'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version prior to Mageia 2's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Mageia 2 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. -- The Mageia Bugsquad
Version: 2 => 3
Mageia 3 changed to end-of-life (EOL) status 4 months ago. http://blog.mageia.org/en/2014/11/26/lets-say-goodbye-to-mageia-3/ Mageia 3 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Mageia please feel free to click on "Version" change it against that version of Mageia and reopen this bug. Thank you for reporting this bug and we are sorry it could not be fixed. -- The Mageia Bugsquad
Status: NEW => RESOLVEDResolution: (none) => OLD
Version: 3 => 4
Reopening, as I suppose the version was changed to 4 in that purpose, then forgotten.
Status: RESOLVED => REOPENEDResolution: OLD => (none)
its being re-opened because its one part in an overarching set of problems dealing with Mageia's authentication against OpenLDAP and Heimdal Kerberos as well as Samba 4. Rosa Linux has made some advancements in that area. They need to be ported to Mageia. Current issues revolve around offline authentication of cached credentials.
Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Mageia version. Bug Reporter: Thank you for reporting this issue and we are sorry that we weren't able to fix it before Mageia 4's end of life. If you are able to reproduce it against a later version of Mageia, you are encouraged to click on "Version" and change it against that version of Mageia. If it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Mageia release includes newer upstream software that fixes bugs or makes them obsolete. If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
The two remaining issues on this bug are the sudo thing and the certificates thing. It'd probably be better to open new bugs for each of those rather than keeping this bug open.
I've sorta falling behind in Mageia. But as far as I know, this is still an issue.
As announced over a month ago, Mageia 4 changed to end-of-life (EOL) status on 2015-09-19. It is is no longer maintained, which means that it will not receive any further security or bug fix updates. This issue may have been fixed in a later Mageia release, so, if you still see it and didn't already do so: please upgrade to Mageia 5 (or, if you read this much later than this is written: make sure you run a currently maintained Mageia version) If you are able to reproduce it against a maintained version of Mageia, you are encouraged to 1. reopen this bug report, by changing the "Status" from "RESOLVED - OLD" to "REOPENED" 2. click on "Version" and change it against that version of Mageia. If you know it's valid in several versions, select the highest and add MGAxTOO in whiteboard for each other valid release. Example: it's valid in cauldron and Mageia 5, set to cauldron and add MGA5TOO. 3. give as much relevant information as possible. If you're not an experienced bug reporter and have some time: please read this page: https://wiki.mageia.org/en/How_to_report_a_bug_properly If you see a similar issue, but are _not_sure_ it is the same, with the same cause, then please file a new bug report and mention this one in it (please include the bug number, too). If you would like to help fixing bugs in the future, don't hesitate to join the packager team via our mentoring program [1] or join the teams that fit you most [2]. [1] https://wiki.mageia.org/en/Becoming_a_Mageia_Packager [2] http://www.mageia.org/contribute/
Status: REOPENED => RESOLVEDResolution: (none) => OLD