Hello, I am trying to join my mageia laptop to my Windows Active Directory and if possible to Azure AD.\ Checking on this webpage; https://docs.microsoft.com/en-us/azure/active-directory-domain-services/join-rhel-linux-vm The problem is that the required packages cannot be found on Mageia.... like realmd it's only available on MGA5. Packages like realmd sssd oddjob oddjob-mkhomedir are not available. Are they included in other packages?. I need to use "realm join --verbose AADDSCONTOSO.COM -U 'contosoadmin@AADDSCONTOSO.COM'" to join.. Please advice. Regards Ezequiel Partida
$ urpmq -y sssd python2-sssdconfig python3-sssdconfig sssd sssd-ad sssd-client sssd-common sssd-common-pac sssd-dbus sssd-ipa sssd-kcm sssd-krb5 sssd-krb5-common sssd-ldap sssd-libwbclient sssd-libwbclient-devel sssd-nfs-idmap sssd-proxy sssd-tools sssd-winbind-idmap I have no experience with active directory. From it's description, sssd-ad may be what is needed.
CC: (none) => davidwhodgins
All online tutorials I saw today refers to a "realmd" binaries. On some RHEL8 / CentOS8 tutos, an install command: # dnf install realmd sssd oddjob oddjob-mkhomedir adcli samba-common samba-common-tools krb5-workstation authselect-compat Some above packages are no equivalent on Mageia. Assigning this as RPM package request. Assigning this package request to all packagers collectively. On a voluntary basis, one of them might, if there are no license or other legal issues, want to integrate it to the distribution and maintain it for bug and security fixes. You might also want to join the packager team to maintain this piece of software: see https://wiki.mageia.org/en/Becoming_a_Mageia_Packager
Target Milestone: --- => Mageia 8Component: RPM Packages => New RPM package requestSummary: How to join mageia to Active Directory => Add realmd and adcli tools from RHEL8/CentOS8 to join Active Directory Domains, NEW PACKAGE REQUEST
CC: (none) => ouaurelienAssignee: bugsquad => pkg-bugs
We do have sssd. adcli is pretty handy and would be nice to have. The current sssd version actually expects that you have it, and uses it to rotate the machine account password periodically. The net command (from Samba) for joining doesn't work reliably with newer Windows versions. The oddjob stuff isn't needed, as we have pam_mkhomedir in the pam package, and that can be used. The realmd package isn't as useful as documentation makes it sound. It does multiple things incompletely and incorrectly by default, so you end up having to fix the configuration manually anyway, it doesn't save much effort over just reading documentation and doing the configuration manually. I wouldn't be in favor of bringing this package back, at least without fixing those things. A better idea would be integrating Active Directory support into drakauth.
CC: (none) => luigiwalser
Hello everyone, Did someone took this?. I just setup my first server in Mageia and would not like to install ubuntu o fedora... I did try Rocky Linux but for my surprise it did not detected my SAS 5 Raid... Mageia 8 on the otherhand works great... I used the draktools to share my server folders but it seems I am not doing thing right since I cannot see them from Windows, but I can read windows shared folders from other servers by typing ¨domain\username¨. I setup samba as a standalone, I wonder if it should be PDC. Are there any documentation on this or on the Mandriva Docs?.. I could not find anything. Regards
This is a nice video on this. So sad that no packages are available for mageia on this. Unfortunately I don´t know hot to pack. https://www.youtube.com/watch?v=3TPgxpjgYsU&t=60s
You should file a separate bug if drakshare isn't working. Standalone and PDC don't sound right, but there are different ways of doing shares (security = share, old, deprecated, and less secure, and security = user, which is more complicated), and then there's the fact that newer Windows have SMBv1 disabled by default so you have to be using SMBv3. Like I said in Comment 3, ignore any articles or videos that tell you to use the realm command. Even when it's available, I don't recommend it unless you know what you're doing. It completely neglects to save the Samba configuration and it gets things wrong in the sssd configuration that you have to fix manually anyway. Oddjob-mkhomedir is needed if SELinux is in use and /home is a local filesystem, as pam_mkhomedir doesn't set SELinux contexts for newly created home directories correctly, but Mageia doesn't support SELinux anyway. Here's some of my notes from Mageia 5, using example.com as the domain (you'll have to change this to whatever your LAN domain is) and $admin as your AD admin account. These are snippets of the key parts of the configurations. urpmi krb5-workstation sssd samba-common /etc/resolv.conf: search example.com nameserver <AD DC IP> /etc/krb5.conf: [libdefaults] default_realm = EXAMPLE.COM kdc_timesync = 0 dns_lookup_realm = true dns_lookup_kdc = true forwardable = true proxiable = true udp_preference_limit = 0 rdns = false /etc/samba/smb.conf: [global] workgroup = EXAMPLE realm = EXAMPLE.COM kerberos method = secrets and keytab security = ads /etc/pam.d/system-auth (each line follows the pam_unix/tcb one): auth sufficient pam_sss.so forward_pass account [default=bad success=ok user_unknown=ignore] pam_sss.so password sufficient pam_sss.so use_authtok session optional pam_sss.so I also had to end the account section with: account required pam_permit.so and start the session section with: session required pam_mkhomedir.so umask=0026 skel=/etc/skel/ silent /etc/nsswitch.conf: passwd: files sss shadow: files sss group: files sss /etc/sssd/sssd.conf: [sssd] domains = example.com config_file_version = 2 services = nss,pam [domain/example.com] cache_credentials = true id_provider = ad access_provider = ad min_id = 1000 ldap_id_mapping = true krb5_store_password_if_offline = true use_fully_qualified_names = false fallback_homedir = /home/%u default_shell = /bin/bash ad_gpo_ignore_unreadable = true Joining domain: # kinit $admin # net ads join -k ## OR if you have adcli built and installed locally # adcli join -U $admin -C --add-samba-data example.com # systemctl restart sssd
From https://bugs.mageia.org/show_bug.cgi?id=33265#c0 : In the past I open this package request and nothing yet is available. https://bugs.mageia.org/show_bug.cgi?id=27369 Since then I've been trying to find easy solution, and I got motivated to learn by myself how to package, I've been getting help from Katnatek and Kekepower who helped me start and guided me on how to package. At work we plan to start with some Linux Desktops for production, unfortunately Mageia doesn't have an easy way to integrate to Active directory, not just for sharing files but also to have user access control and permissions to windows share folders, on the other hand, distros like Ubuntu and Fedora have an option on the install and/or login that makes it easy to integrate to active directory as well as AD login/logout.. I wonder why mageia doesn't have it. So I plan to find the necessary tools to make mageia integrate with AD. I just hope this also gets mageia support as well. If someone knows a little on what we already have and need it will be very much appreciated. We might have the necessary tools already but there is no GUI integration yet
CC: (none) => lewyssmithSummary: Add realmd and adcli tools from RHEL8/CentOS8 to join Active Directory Domains, NEW PACKAGE REQUEST => Add tools for Active Directory Integration, NEW PACKAGES REQUEST
*** Bug 33265 has been marked as a duplicate of this bug. ***
Comment 7 above was by Ezequiel, not me! Can you start by defining what new packages you foresee? Bear in mind luigi's comments 3 & 6.
Yeah it's not really a matter of packaging something. There isn't really a magical solution out there. The framework exists in drakauth to support this. Someone just needs to do the programming work to integrate support for it (and if that's done, it can also be integrated into the installer).
(In reply to David Walser from comment #6) > You should file a separate bug if drakshare isn't working. Standalone and > PDC don't sound right, but there are different ways of doing shares > (security = share, old, deprecated, and less secure, and security = user, > which is more complicated), and then there's the fact that newer Windows > have SMBv1 disabled by default so you have to be using SMBv3. > > Like I said in Comment 3, ignore any articles or videos that tell you to use > the realm command. Even when it's available, I don't recommend it unless > you know what you're doing. It completely neglects to save the Samba > configuration and it gets things wrong in the sssd configuration that you > have to fix manually anyway. Oddjob-mkhomedir is needed if SELinux is in > use and /home is a local filesystem, as pam_mkhomedir doesn't set SELinux > contexts for newly created home directories correctly, but Mageia doesn't > support SELinux anyway. > > Here's some of my notes from Mageia 5, using example.com as the domain > (you'll have to change this to whatever your LAN domain is) and $admin as > your AD admin account. These are snippets of the key parts of the > configurations. > > urpmi krb5-workstation sssd samba-common > > /etc/resolv.conf: > search example.com > nameserver <AD DC IP> > > /etc/krb5.conf: > [libdefaults] > default_realm = EXAMPLE.COM > kdc_timesync = 0 > dns_lookup_realm = true > dns_lookup_kdc = true > forwardable = true > proxiable = true > udp_preference_limit = 0 > rdns = false > > /etc/samba/smb.conf: > [global] > workgroup = EXAMPLE > realm = EXAMPLE.COM > kerberos method = secrets and keytab > security = ads > > /etc/pam.d/system-auth (each line follows the pam_unix/tcb one): > auth sufficient pam_sss.so forward_pass > account [default=bad success=ok user_unknown=ignore] pam_sss.so > password sufficient pam_sss.so use_authtok > session optional pam_sss.so > > I also had to end the account section with: > account required pam_permit.so > > and start the session section with: > session required pam_mkhomedir.so umask=0026 skel=/etc/skel/ silent > > /etc/nsswitch.conf: > passwd: files sss > shadow: files sss > group: files sss > > /etc/sssd/sssd.conf: > [sssd] > domains = example.com > config_file_version = 2 > services = nss,pam > [domain/example.com] > cache_credentials = true > id_provider = ad > access_provider = ad > min_id = 1000 > ldap_id_mapping = true > krb5_store_password_if_offline = true > use_fully_qualified_names = false > fallback_homedir = /home/%u > default_shell = /bin/bash > ad_gpo_ignore_unreadable = true > > Joining domain: > # kinit $admin > # net ads join -k > ## OR if you have adcli built and installed locally > # adcli join -U $admin -C --add-samba-data example.com > # systemctl restart sssd Ok. I did all stepss you recommended.. the first time I replaced everything on those .config files and I was unable to login so I reinstalled and added/modified only the infor you gave me... and still didn't work. $kinit username@domain kinit: KDC reply did not match expectations while getting initial credentials So I tracked my keberos server from my windows PC using: nslookup -type=srv _kerberos._tcp.YOUR-DOMAIN Once I got the correct kerberos server I added it to /etc/nostname as well as /etc/krb5.config default_realm = EXAMPLE.COM kinit also did not gave me anything.. same error. once I used command systemctl restart sssd I got a error. There was no .config file so I created it. # systemctl restart sssd Job for sssd.service failed because the control process exited with error code. See "systemctl status sssd.service" and "journalctl -xeu sssd.service" for details. I created the ssd package from cauldron to test,,, mga9 has 2.8.2 while cauldron has 2.9.5. This new one did not gave me any errors but systemctl statys sssd show: systemctl status sssd ○ sssd.service - System Security Services Daemon Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled) Active: inactive (dead) Condition: start condition failed at Thu 2024-06-13 12:29:05 PDT; 2min 44s ago ├─ ConditionPathExists=|/etc/sssd/sssd.conf was not met └─ ConditionDirectoryNotEmpty=|/etc/sssd/conf.d was not met
I upgraded to cauldron to see if it has to do with older adcli and dependencies and I got the next messages... where it says user and domain I had my current username and domain name. @adcli join domain.com -U user@domain.com Password for user@domain.com: adcli: couldn't connect to domain.com domain: Couldn't get kerberos ticket for: user@domain.com: KDC reply did not match expectations
Hello everyone, Today I almost gave up on this, I installed ubuntu againt to see it working.. and I did more reseach on this. Looking at the tools that ubuntu and fedora I had to givet it a last try.. I know David Walser told me not to use realm... Sorry but I had to try. So I created the mageia package of realm, oddjob and oddjob_mkdhomedir... sssd is already in mga9 and I had to backport adcli from cauldron. A root this is what happened. realm discover -v * Resolving: _ldap._tcp.littletwinkie.com * Performing LDAP DSE lookup on: 10.10.4.5 * Performing LDAP DSE lookup on: 172.30.0.10 * Performing LDAP DSE lookup on: 192.168.1.210 * Successfully discovered: littletwinkie.com littletwinkie.com type: kerberos realm-name: LITTLETWINKIE.COM domain-name: littletwinkie.com configured: kerberos-member server-software: active-directory client-software: winbind required-package: oddjob required-package: oddjob-mkhomedir required-package: samba-winbind required-package: samba-winbind-clients required-package: samba-common-tools Then I typed: '' sudo real join -v -U ezequiel.partida@littletwinkie.com --membership-software=samba --client-software=winbind littletwinkie.com I followed the steps and at the end I got: * Successfully enrolled machine in realm. :-) Once rebooted as was able to login as user: ezequiel.partida@littletwinkie.com Also forlder /home/ezequiel.partida@littletwinkie was created. I can also access sharefolders on my file serve using dophin with smb://twinkiesvr All permissions seems to be working same as windows does. So, what you guys think?
Your user name should just be ezequiel.partida, but realm misconfigures the use_fully_qualified_names setting in sssd.conf. Unless it's changed since the last time I used it, it also fails to save the samba configuration, so the net command won't work. On modern systems, you probably need to use adcli (not net) for joining (net also has other functions). Realm uses adcli in the background. Otherwise, you can check what it did to the configuration files mentioned above to see what a mostly correct configuration is supposed to look like. We just need drakauth to replicate that, without the mistakes that realm makes.
Hello David Today I had time to do a fresh reinstall and I was able to join the domain in a second using kinit. The only problem is that once I try to login as ezequiel.partida it won't take it, I login as local userand ran drakauth after joining the domain and now I am stuck at logon since it just freezes there. I wonder.. all the instructions you gave me before, should I replace the files you told me to modify or just merge them with what's already on the files except whats duplicated?
From what I gave in Comment 6, the following were complete files: resolv.conf krb5.conf sssd.conf and the following were snippets that would be merged in: smb.conf system-auth nsswitch.conf Obviously where the latter will get you will depend on what's already there. You would likely have more luck with the system in the fresh state, rather than post-drakauth. You can also try repeating what you did in Comment 13, but fix sssd.conf as I mentioned in Comment 14 (there is also a realm.conf setting you can put in place before calling realm to pre-emptively fix it), and save the smb.conf changes I've described, which realm fails to, and then see (assuming it's all working) what the correct config files should look like (which should be pretty close to what I gave, but you can post any deviations here). Let me know if you have any questions.
I Just want to let you know that I found. I noticed I wasn't joining the domain because I did not have the right info on /etc/resolv.conf This has to be like the next example. domain example.com search example.com nameserver x.x.0.10 #for Primary nameserver x.x.4.5 #for Secondary On konsole I ran drakauth, on the UI I chose windows Domain and I was able to choose my domains from it.. I later noticed on konsole that drakauth joined my domain in a snap and smb.conf, krb5.conf, nsswitch.conf were updated, except /etc/sssd/sssd.conf drakauth created the next /etc/nsswitch.conf (I wonder if I shoulr remove winbind or not... I'll do test with and without it and add sss. passwd: files winbind shadow: files winbind group: files winbind hosts: mdns4_minimal files nis dns mdns4 myhostname networks: files dns services: files protocols: files rpc: files ethers: files netmasks: files netgroup: files publickey: files bootparams: files automount: files winbind aliases: files I repeat that I did in Comment 13
winbind, oh my, I'm surprised that still works. So the good thing is that it should be joined, i.e. /etc/krb5.keytab should be valid. Sssd has been the main accepted way of doing AD integration for years now. When switching to that, both /etc/nsswitch.conf and /etc/pam.d/system-auth will need to be updated. Note that sssd and winning have different algorithms for calculating UIDs, so you will have to fix the ownership of your home directory.
I've done 5 fresh installs to make test, and the only way I've been able to join the domain is either using drakauth or using realm. drakout joins very fasts and efective, the only problem is what once joined and I restart my laptop I cannot login using my network account.. I tried using ezequiel.partida, domain\ezequiel.partida, ezequiel.partida@domain.com, etc. with no success. I've tried adcli but it seems not to detect my kerberos server, I've googled around, changed all files you recommended and still cannot login, I did find some information that mentions that pam sometimes fails on certain configurations, I wonder if it has to do with certain versions of windows servers or AD.. We use legacy AD at work but our main domain is on Azure. This is what I got: $ adcli join -U $admin -C --add-samba-data example.com After around a minute I got: adcli: couldn't connect to example.com domain: Couldn't authenticate to active directory: SASL(-4): no mechanism available: No worthy mechs found Like I mentioned before, I used drakauth to join the domain and then replace everything that said winbind with sss with no success since once I tried to login it din't work using just username: ezequiel.partida or domain/ezequiel.partida. So I went ahead and created the packages I used before realm, addjobm, oddjob_mkhomedir, authselect and realm... I had to add Provices: samba-common-tools to samba to make it work since it seems realm needs it. After installing them this is what I got: # realm join -v -U ezequiel@example.com --membership-software=samba --client-software=winbind example.com * Resolving: _ldap._tcp.sfl.sealforlife.com * Performing LDAP DSE lookup on: 192.168.x.x * Performing LDAP DSE lookup on: 192.168.x.x * Performing LDAP DSE lookup on: 172.x.x.x * Successfully discovered: example.com Password for ezequiel@example.com: * Required files: /usr/sbin/oddjobd, /usr/libexec/oddjob/mkhomedir, /usr/sbin/winbindd, /usr/bin/wbinfo, /usr/bin/net * LANG=C LOGNAME=root /usr/bin/net --configfile /var/cache/realmd/realmd-smb-conf.38PUZ2 -U ezequiel@example.com --use-kerberos=required ads join example.com Password for [ezequiel@example.com]:kerberos_kinit_password ezequiel@example.COM failed: Cannot contact any KDC for requested realm DNS update failed: NT_STATUS_INVALID_PARAMETER Using short domain name -- SFL Joined 'TJM-BENCHLNX1' to dns domain 'example.com' No DNS domain configured for tjm-benchlnx1. Unable to perform DNS Update. * LANG=C LOGNAME=root /usr/bin/net --configfile /var/cache/realmd/realmd-smb-conf.38PUZ2 -U ezequiel@example.com ads keytab create Password for [ezequiel@example.com]:kerberos_kinit_password ezequiel@example.com failed: Cannot contact any KDC for requested realm * /usr/bin/systemctl enable winbind.service Created symlink /etc/systemd/system/multi-user.target.wants/winbind.service → /usr/lib/systemd/system/winbind.service. * /usr/bin/systemctl restart winbind.service * /usr/bin/sh -c /usr/bin/authselect select winbind with-mkhomedir --force && /usr/bin/systemctl enable oddjobd.service && /usr/bin/systemctl start oddjobd.service Backup stored at /var/lib/authselect/backups/2025-01-04-04-07-37.FgRkr2 Profile "winbind" was selected. Make sure that winbind service is configured and enabled. See winbind documentation for more information. - with-mkhomedir is selected, make sure pam_oddjob_mkhomedir module is present and oddjobd service is enabled and active - systemctl enable --now oddjobd.service Created symlink /etc/systemd/system/multi-user.target.wants/oddjobd.service → /usr/lib/systemd/system/oddjobd.service. * Successfully enrolled machine in realm After this I was able to see my computer on AD OU. I was able to login using domain\ezequiel.partida it didn't take it as ezequiel.partida, I've tried ubuntu and I had to login as domain\exequiel.partida. I am able to use dolphin and browse all my share folders on my servers as well. I still need to do some testing on sharing mageia folders with windows and adding permissions with AD validation. We have 1 mageia 9 server using a program called Ingition for industrial automation from https://www.vertech.com/ .
realm uses adcli to do the join, it just sets up some configs beforehand. You can use pam_mkhomedir, rather than the oddjob version, as I've mentioned before. You can fix the username issue by setting use_fully_qualified_names = false in /etc/sssd/sssd.conf. Check the config files that I've mentioned before (except smb.conf, as realm neglects to save it, so you have to do that one manually) to see what realm did that you were missing previously, and you should be able to replicate it without realm.
Oh weird, it looks like in your case it used the net command to do the join. That's the old way. It doesn't even work with newer AD servers IINM. It also appears to be using winbind, which is even weirder.
I've tried Fedora and ubuntu and they also require domain\user and they also create the user profile as user@domain I guess oddjob_mkhomedir does that. I've done everything you told me to just use username without doing domain\username but haven't been able to log or even join the domain.. Drakauth does a great job joining the domain using winbind but I cannot login for some reason. I wonder if realm does alternative ways to join in some windows environments (net, winbind, etc) to be able to work.. same as oddjob. Mageia works great with realm, addjobm, oddjob_mkhomedir, authselect combination, but with everything you mentioned before I guess this packages may not be available for mageia in the future. In this case, it would be great to update drakauth and family to be able to interact with windows serves especially AD in a mixed windows and linux network environment... In my case I really prefeer Mageia, I found mageia to work much better than ubuntu and fedora on this but the Engineering department (at work) asked me to find a solution or move the mageia servers to fedora or ubuntu. I've already told them I can maintain the packages myself but they are kind of scared of what's going to happen if I move to another job. :-)
As I mentioned before, realm has a configuration parameter that you have to put in place before running it to make the regular username work without the domain. I also pointed out how to fix that after the fact with sssd, but I don't know off the top of my head how to do that with winbind. Oddjob doesn't control any of this, it just creates the home directory at login. Mageia can also work fine with what it has, if you configure it correctly.
It seems that redhat is deprecating pam_mkhomedir.. But they are not very clear if it's the case or not. https://access.redhat.com/discussions/903523 https://bugzilla.redhat.com/show_bug.cgi?id=903880 https://bugzilla.redhat.com/show_bug.cgi?id=863132 https://danwalsh.livejournal.com/69837.html
Yes, and that doesn't impact us at all. They use oddjob instead because pam_mkhomedir doesn't set SELinux attributes, which matters for them, but not us. Also, I was looking at realmd at work last week, and saw that it gives you the option of using winbind or sssd. You should have it use sssd, if you'd like to figure out why you were unable to get it working manually.
Created attachment 14912 [details] Spec for authselect I don't know what Suggest(meta) does for Fedora my best now is convert to recommends but not looks the best option Recommends: sssd Recommends: samba-winbind Recommends: fprintd-pam Recommends: oddjob-mkhomedir Perhaps could make metapackages or add virtual provide in the related specs ?
Created attachment 14913 [details] Spec for oddjob I will like to make it work with pam_mkhomedir but not have resources to play and fine tune. So I suggest to work with tools that works and are expected
Created attachment 14914 [details] Spec for realmd
If David Walser is not against , I will like to import these packages to mageia
CC: (none) => j.alberto.vc
It's not as simple as importing authselelect, as the whole distro would have to be converted to use it, which would impact other packages, drakconf, the installer, and documentation. Oddjob is only needed with SELinux. Realmd as-is has some issues, and again would need to be integrated with other code in the distro. Simply importing those packages isn't the solution.
(In reply to David Walser from comment #30) > It's not as simple as importing authselelect, as the whole distro would have > to be converted to use it, which would impact other packages, drakconf, the > installer, and documentation. Oddjob is only needed with SELinux. Realmd > as-is has some issues, and again would need to be integrated with other code > in the distro. Simply importing those packages isn't the solution. I not see why, if the work can be done it by hand running oddjob-mkhomedir The reporter is not expecting any integrations in our tools Well if the last decision is we don't like this packages in mageia I'll kept them as unofficial then
There's no purpose to importing them, as they don't really provide a capability that we don't already have (and would probably just cause confusion).
(In reply to katnatek from comment #31) > (In reply to David Walser from comment #30) > > It's not as simple as importing authselelect, as the whole distro would have > > to be converted to use it, which would impact other packages, drakconf, the > > installer, and documentation. Oddjob is only needed with SELinux. Realmd > > as-is has some issues, and again would need to be integrated with other code > > in the distro. Simply importing those packages isn't the solution. > > I not see why, if the work can be done it by hand running oddjob-mkhomedir > The reporter is not expecting any integrations in our tools > > Well if the last decision is we don't like this packages in mageia I'll kept > them as unofficial then I agree with you Katnatek.. I actually don´t see any problem with the packages I have, they work like a charm and I don't have any problems with drakconf or any other. One difference with mandrake, mandriva and mageia is that they are much easier that other distros to setup and configure except with AD stuff.