Re: [Freeipa-users] Can an Active Directory domain be the default domain?
On Mon, Apr 13, 2015 at 01:02:18PM -0400, David Guertin wrote: Said that, you can set default domain in SSSD configuration on the legacy clients (RHEL 5) as then SSSD will ensure proper fully-qualified name will be sent towards compat tree and non-qualified name can be asked on the client (RHEL 5) side. I was able to do this on RHEL 6/sssd 1.11 with default_domain_suffix = middlebury.edu, and it works great. But that command does not work with RHEL 5/sssd 1.5. Is there a comparable sssd.conf setting for older sssd versions? I'm afraid there is not. The AD entries in the compat tree are fully qualified anyway and in the same tree as IPA users, there needs to be a way to distinguish them.. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Synology DSM5 and freeIPA
Just a follow up. I thought that making NFS a service in IPA takes care of this, but it looks like the issues are unrelated. Home directories are created automatically if the user logs in to the NFS server, but I haven't found any solution to trigger this from a client without using no_root_squah for the mount on the IPA server. If someone has achieved this functionality, can you share your experience ? On Fri, Apr 10, 2015 at 1:05 PM, Prasun Gera prasun.g...@gmail.com wrote: Here's the link: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/users.html#home-directories On Fri, Apr 10, 2015 at 12:42 PM, Dmitri Pal d...@redhat.com wrote: On 04/09/2015 07:44 PM, Prasun Gera wrote: I have a somewhat related question. Without kerberizing NFS, which I'll do eventually since that needs all the clients to be migrated first, how does one create home directories automatically ? The IPA server and NFS server are different systems. I was able to verify that automatic home creation works if the NFS share is exported to the IPA server with no_root_squash. What's the proper way of doing this ? The documentation says: Which documentation you are referring to? Can you please post the link? Use a remote user who has limited permissions to create home directories and mount the share on the IdM server as that user. Since the IdM server runs as an httpd process, it is possible to use sudo or a similar program to grant limited access to the IdM server to create home directories on the NFS server. What would be the list of steps that would achieve this ? What are the limited permissions that the NFS user would need ? Read + Write, but no Delete to the /home directory ? Sounds like something that would need ACLs. And where does sudo on the IPA server fit into this ? On Thu, Mar 19, 2015 at 4:51 PM, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: Thanks, Jakub. On 19 March 2015 at 21:23, Jakub Hrozek jhro...@redhat.com wrote: On 19 Mar 2015, at 21:18, Roberto Cornacchia roberto.cornacc...@gmail.com wrote: It's possible that I'm simply not getting the point, or that I don't understand the documentation correctly, but this is what I don't find clear: I had seen the instructions you pointed me at. These are not specifically about home directories. However, this section is: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs It first suggests that automatic creation of home directories over NFS shares is possible: just automount /home and then use pam_oddjob_mkhomedir or pam_mkhomedir to create homedirs at first login. But then it also suggests that mounting the whole /home tree could be an issue, and says: Use automount to mount only the user's home directory and only when the user logs in, rather than loading the entire /home tree. That means that automatic homedir creation is out of the game, doesn't it? That's what I find confusing. What's the recommended way? It really depends on your environment. For your size, it's perfectly fine to NFS mount the whole /home tree and be done with it. Don't optimize prematurely :-) On 19 March 2015 at 20:49, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 02:46 PM, Roberto Cornacchia wrote: Hi Dmitri, I do realise my question is borderline and I accept that it is considered off-topic. I did post it here because I believe it's not *only* about NFS, but also about its interaction with freeIPA. The issue of NFS home and in particular about their creation is touched in all the links I posted (all about freeIPA) and never really answered. This is what documented and recommended: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs RHEL6 has a similar chapter in its doc set though books have changed significantly between 6 and 7. I do not see any chicken and egg problem there. The instructions show how to create home dirs on the first login. It mounts the volume and then creates dirs on it as users log in if they are not already there. It is unclear what problem you see with doing it the way it is recommended. Best, Roberto On 19 March 2015 at 19:36, Dmitri Pal d...@redhat.com wrote: On 03/19/2015 05:29 AM, Roberto Cornacchia wrote: On 6 March 2015 at 11:15, Martin Kosek mko...@redhat.com wrote: On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: Hi there, I'm planning to deploy freeIPA on our lan. It's small-ish and completely based on FC21, so I expect everything to work like a charm. Except one detail. We have Synology NAS station, which uses DSM 5.0. The ideal plan is to use it as host for shared NFS home dirs
Re: [Freeipa-users] Checking 389 for ACI contamination
On Apr 13, 2015, at 1:33 PM, Martin Kosek mko...@redhat.com wrote: On 04/12/2015 05:27 AM, Brian Topping wrote: Hi all, trying to figure out if I may have contaminated my ACIs in the process of upgrading my replicated deployment. I didn't upgrade the instances at the same time, is there any possibility that the 3.x ACIs contaminated the 4.x DIT? What do you mean, by... contaminated? Can you please described what exactly happened? As Dmitri said, there were major ACI related changes in 4.0, but I am not sure what is the problem in your case. The only thing that is broken at the moment is my OCD. I did make a couple of changes in my 3.x deployment that appear to have been insufficient when I upgraded, but I didn't name them well and I'm having issues trying to find which ones they were. Now that I've RTFM on ACIs, I want to make sure everything that is there is there for a reason. I'd rather put effort in now than be surprised by some cruft I left behind in a future upgrade. If so, how would I check it? Is there an LDIF in the disto that I can manually compare the entries? I am not sure which entries are you referring to. But from 4.0, most of the ACIs are now generated dynamically, from Python code. If the schema/ACIs are managed by Python, it might be interesting for the script to generate warnings when it runs. Stuff like missing/extra schema ACIs. Just a thought. signature.asc Description: Message signed with OpenPGP using GPGMail -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] CRON: Authentication service cannot retrieve authentication info
Hi, It's an in-house program which runs on one kerberos user. On Tue, Apr 14, 2015 at 5:34 AM, Dmitri Pal d...@redhat.com wrote: On 04/13/2015 08:23 AM, Thomas Lau wrote: Hi, These problem appear randomly, sometime it still work even under heavy packet loss, some times would be like this. So its hard to catch. On Apr 13, 2015 3:22 PM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:15:09PM +0800, Thomas Lau wrote: Hi all, We have cronjob which running on a FreeIPA LDAP user; When connection between IPA server and client having heavy packet loss, following error would occur: CRON[20637]: Authentication service cannot retrieve authentication info I have cache credentials and store password if offline enabled on sssd, how these problem would still happening? It might be that the cause of the problem is actually the packet loss or some kind of delay. SSSD might not think that it is offline but cron job itself times out and reports failure. Do you know what operation in the job fails? sssd.conf: cache_credentials = True krb5_store_password_if_offline = True Did the use log in at least once offline? You can verify if the password has been cached using the ldbsearch utility. It would be best to catch the occurence of the problem in logs. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Thomas Lau Director of Infrastructure Tetrion Capital Limited Direct: +852-3976-8903 Mobile: +852-9323-9670 Address: 20/F, IFC 1, Central district, Hong Kong -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Upgrading Freeipa 3 server.
One of our environments has a Freeipa3 sever installed and I need to upgrade it to FreeIPA 4. I brought up RHEL 7 server and installed FreeIPA 4 as a replica of the FreeIPA3 box. But now I’m stuck. I can’t find any good documentation on how to promote the new FreeIPA4 server and take the old FreeIPA3 server out of the picture. If I do a ida-replica-manage del —force stip01.staging.fioptics.int it tells me I can’t because it would leave me without a CA. However I can’t find any documentation on migrating the CA from IPA3 to IPA4. Any help would be appreciated. Regards, -- Aric Wilisch awili...@gmail.com -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Upgrading Freeipa 3 server.
On 04/13/2015 07:26 PM, Aric Wilisch wrote: One of our environments has a Freeipa3 sever installed and I need to upgrade it to FreeIPA 4. I brought up RHEL 7 server and installed FreeIPA 4 as a replica of the FreeIPA3 box. But now I'm stuck. I can't find any good documentation on how to promote the new FreeIPA4 server and take the old FreeIPA3 server out of the picture. If I do a ida-replica-manage del ---force stip01.staging.fioptics.int it tells me I can't because it would leave me without a CA. However I can't find any documentation on migrating the CA from IPA3 to IPA4. Any help would be appreciated. Regards, -- Aric Wilisch awili...@gmail.com mailto:awili...@gmail.com Did you follow this procedure? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#migrating-ipa-proc I would say that I would recommend upgrading to 6.6 rather than 6.5. If you did not what exactly did you do? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Upgrading Freeipa 3 server.
I didn’t see this guide until now. The IPA3 server started off as a RHEL 6.6 server so no upgrade is necessary, but I simply generated the replica file and created the IPA 4 server as a replica. Aside from the CA not being there the server looks to be working fine and shows up as a master. I’ll uninstall the 4 server and work through the script process to see if that fixes the issue. Regards, -- Aric Wilisch awili...@gmail.com On Apr 13, 2015, at 7:47 PM, Dmitri Pal d...@redhat.com wrote: On 04/13/2015 07:26 PM, Aric Wilisch wrote: One of our environments has a Freeipa3 sever installed and I need to upgrade it to FreeIPA 4. I brought up RHEL 7 server and installed FreeIPA 4 as a replica of the FreeIPA3 box. But now I’m stuck. I can’t find any good documentation on how to promote the new FreeIPA4 server and take the old FreeIPA3 server out of the picture. If I do a ida-replica-manage del —force stip01.staging.fioptics.int it tells me I can’t because it would leave me without a CA. However I can’t find any documentation on migrating the CA from IPA3 to IPA4. Any help would be appreciated. Regards, -- Aric Wilisch awili...@gmail.com mailto:awili...@gmail.com Did you follow this procedure? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#migrating-ipa-proc https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#migrating-ipa-proc I would say that I would recommend upgrading to 6.6 rather than 6.5. If you did not what exactly did you do? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] user account without password
Hello, usually domain users used to run services AND to make some administration work. Some of users only used to run services. Also, there is a number of domain users, for example, oracle which is very important for application life, so we duplicating such users locally, to make sure it resolving is not depend on sssd (we still not thinking it is completely rock-stable, sorry :)). I have limited experience with NFS and domain users, in case of security, anyway. We do have a special nfs server sharing its filesystems to other services and using the same domain user on all this servers. For now I cannot remember any issues related this complex. -Original Message- From: Nordgren, Bryce L -FS [mailto:bnordg...@fs.fed.us] Sent: Monday, April 13, 2015 9:19 PM To: Alexander Frolushkin (SIB); 'Martin Kosek'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] user account without password Hi Alex, Just because I gave up doesn't mean there isn't a way. Does your partitioning of local/domain users allow a domain user to run a service on a machine? I was trying to run an iPython notebook server as my regular user/domain account via systemd. Much of the data that the service needed access to resided on a multi-Terabyte NFS share, hence the desire to make it work with my domain account. IIRC, systemd was the thing choking on the domain user. Do you just manually create a local user with the same attributes as the domain user? (and in the case of the above use NFS with sec=host)? Thanks, Bryce -Original Message- From: Alexander Frolushkin [mailto:alexander.frolush...@megafon.ru] Sent: Sunday, April 12, 2015 9:27 PM To: Nordgren, Bryce L -FS; 'Martin Kosek'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] user account without password -Original Message- From: Nordgren, Bryce L -FS [mailto:bnordg...@fs.fed.us] Sent: Friday, April 10, 2015 9:27 PM To: Alexander Frolushkin (SIB); 'Martin Kosek'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] user account without password Also, if such account will also exist locally (my case), it will not be controlled by HBAC rules - it can be a some kind of security trap... Pretty sure accounts should be either local or domain-wide, but not both. Could lead to strange and unforeseen side effects. Last I checked, only local accounts can run services. It may be advantageous to allow local accounts (which can run services) to have a representation in the domain, but the local accounts need to be scoped to the local machine (e.g., apache on server 1 is different than apache on server 2). At least that way, they could belong to the same groups domain accounts belong to. SSO certainly shouldn't work. Any access to shared storage should distinguish between same-named accounts on different machines. Alternatively, allowing domain accounts to run certain services also has some merit. (assuming the user has permissions to do so.) Just thinking into email. Bryce I have a long and positive experience using both local and IPA users with the same attributes, but without HBAC and without sudo way to obtain shell of such users. Default settings in nsswitch.conf and pam provides straight and clear systems behavior, for about three years. But I agree there can be case when such construction may lead to misbehavior and so on. We will try to avoid them. SSO not really the aim for us, we just need to made a environment where users must remember only one password to access all resources on unix/linux servers. Not trying to argue, just sharing some thoughts :) Alexander Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50
Re: [Freeipa-users] CRON: Authentication service cannot retrieve authentication info
On Mon, Apr 13, 2015 at 01:15:09PM +0800, Thomas Lau wrote: Hi all, We have cronjob which running on a FreeIPA LDAP user; When connection between IPA server and client having heavy packet loss, following error would occur: CRON[20637]: Authentication service cannot retrieve authentication info I have cache credentials and store password if offline enabled on sssd, how these problem would still happening? sssd.conf: cache_credentials = True krb5_store_password_if_offline = True Did the use log in at least once offline? You can verify if the password has been cached using the ldbsearch utility. It would be best to catch the occurence of the problem in logs. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS questions
Hello! On 11.4.2015 12:08, Christoph Kaminski wrote: have some questions about DNS in IPA... first some info to our DNS structure: we have 4 internale domains and a lot of subdomains, for example: domain: ourdom.int subdomains: - mgmt.ourdom.int - io.ourdom.int - app.ourdom.int Before we dive into details, please note that you *should not* be using DNS names which were not delegated to you. I.e. it is a bad idea to use 'ourdom.int' unless the domain 'ourdom.int' is really registered to your name. See http://www.freeipa.org/page/DNS#Caveats It is going to cause problems when: - some other company will start using the same name on public Internet - you will merge with other company using the same name - DNSSEC validation is enabled (technically you are 'hijacking'/'shadowing' the name and DNSSEC will detect that) Questions: 1. How we should build the zones in ipa? should each subdomain get a zone? I see I can make only one zone for the domain and put there the subdomain records to (like myhost.mgmt then it resolvs as myhost.mgmt.ourdom.int) What is the right way for this? Technically this is up to you. Is there a difference between the ways? Zone transfers, access control, and zone delegation are done on zone level. I.e. smaller zones give you more control over these aspects. It really depends on your use-case what you prefer. Technically it is perfectly fine to keep everything in single zone. (we got problems with IPA 4.1 to load the zones for domains because our IPA server are 'inside' the mgmt subdomain. It was necessary to put a A record for the IPA servers into the domain. Example: ipa1.mgmt . Without this record the resolving for subdomains has worked but not for the domains... With IPA 3.3.3 we didnt have this problem) I do not fully understand what you mean. Could you described the example in whole, please? What exactly was in the non-functional configuration? What error messages/symptoms did you see? How did you change the configuration to fix it? Thank you! 2. We have 8 IPA Server here (because all our domains are blackboxes, the hosts can communicate only with 2 IPA servers inside the blackbox, IPA server can connect each other over a special out of band network). What should be inside the NS record of each domain? All IPA servers (the hosts inside the blackbox can reach only 2) or only the 2 reachable? I'm not 100 % sure what you mean by 'blackbox'. Generally NS records should contain only servers reachable from other parts of the network. DNS resolvers try to contact servers listed in NS records when querying for records in given zone. Servers which are not reachable but listed in NS records will cause to timeouts. Have a nice day! -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica status 'last update ended'
On 04/13/2015 08:31 AM, Martin Kosek wrote: On 04/11/2015 11:34 AM, Christoph Kaminski wrote: Hi All with the cmd: ipa-replica-manage -v list myipaserver I can see the status of the replication... But I dont understand the field 'last update ended'. What shows the field? The last SUCCESSFULLY update? The last TRY to update? Something else? I want to code some monitoring (nagios/icinga) checks for IPA and I need a authoritative statement/information about the replica status. It is the right place? I think so, this shows the nsds5replicalastupdateend field. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaLastUpdateEnd.html CCing Thierry to confirm. Hello, A master starts a replication session to a replica. During this session it checks which updates are missing and is sending them. Then it closes the replication session. If the replica is already up to date, the master will send no update. The timestamp nsds5replicalastupdateend, is the time when the master has sent all the missing updates (possibly 0 if the replica is up to date) and has no more update to send. The master is waiting for the replica response (on each update) before setting this timestamp. If an error occurred while sending an update the master resets 'nsds5replicaLastUpdateStart' timestamp. thanks thierry -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Replica status 'last update ended'
On 04/11/2015 11:34 AM, Christoph Kaminski wrote: Hi All with the cmd: ipa-replica-manage -v list myipaserver I can see the status of the replication... But I dont understand the field 'last update ended'. What shows the field? The last SUCCESSFULLY update? The last TRY to update? Something else? I want to code some monitoring (nagios/icinga) checks for IPA and I need a authoritative statement/information about the replica status. It is the right place? I think so, this shows the nsds5replicalastupdateend field. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.0/html/Configuration_and_Command_Reference/Configuration_Command_File_Reference-Replication_Attributes_under_cnReplicationAgreementName_cnreplica_cnsuffixName_cnmapping_tree_cnconfig-nsDS5ReplicaLastUpdateEnd.html CCing Thierry to confirm. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Promoting a replica to a FreeIPA server without primary server
Thank you, Rob for your response On 08.04.2015 21:07, Rob Crittenden wrote: I assume you can't do this because the original host is lost, right? Year, you right. Every IPA master is a equal, some are just more equal than others. The key bit that distinguishes them is whether there is a CA installed. The other bit has to do with CRL generation and renewal which in your version can only be done on one host (neither of which apply to --selfsign anyway). I want to clarify, I didn't use --selfsign key during primery server installation. I suppose it's default key for CA, am I wrong? On mycurrent ipa server (replica) I haven't CA. You mention migrating. What new primary server? I'm telling about installation of new freeipa server and copy all data there. So I'd start digging around to see if you have the original CA private key somewhere. The end of the IPA server install would have recommending backing up cacert.p12. I have backup of cacert.p12 key. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] .LDAPUpdate: ERROR Add failure missing required attribute objectclass
On 04/11/2015 09:51 PM, Traiano Welcome wrote: Hi I got this error while installing an IPA replica of my primary master IDM server: .LDAPUpdate: ERRORAdd failure missing required attribute objectclass Replica add command: ipa-replica-install --setup-ca --setup-dns --no-forwarders /var/lib/ipa/replica-info-siteX-idm-slve.lol.local.gpg A little more context: --- . . . Done configuring ipa-otpd. Applying LDAP updates ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure missing required attribute objectclass ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure missing required attribute objectclass ipa.ipaserver.install.ldapupdate.LDAPUpdate: ERRORAdd failure missing required attribute objectclass ipa : ERRORAnonymous ACI not found, cannot update it Restarting the directory server Restarting the KDC Restarting the certificate server Using reverse zone xxx.16.172.in-addr.arpa. --- What does this error mean? If it's suggesting that somehow a key ldap attribute was not created, how can I fix this? Most probably, update process tried to add members to some object/role/privilege, it did not exist so it tried to add just the members, which failed as objectclass is required for new objects. We would need to see ipareplica-install.log, to see which attribute it was. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Multi-Master IPA deployment with AD Trusts: Stability and Consistency Expectations?
On Mon, 13 Apr 2015, Traiano Welcome wrote: Hi List The deployment I'm contemplating is as follows: 1. FreeIPA master at a central site,with AD Trust established to the primary DC. 2. Replicas of the FreeIPA master at 4 other sites (with varying WAN latency between central and site),with replication agreements only with to the master at the central site. (So the AD trust is estalished only between the master IPA server and the primary AD domain controller) There is also an existing domain controller at each site that synchs to the primary domain controller at the main site. I'd like AD user access to Linux systems at each site to be stable and consistent as possible, so to rule out the effect of WAN latency and possibly intermittent connectivity (and a host of possibly other unknown factors), I plan to establish an AD trust between the replica at each site and the local AD domain controller. My thinking is that AD user accounts information will then be available to the replica almost as soon as it's available to the AD dc at that site. So ultimately, the consistency of user information should be as good as can be expected from AD's cross wan replication to remote sites, even if the synchronisation between a replica and master is not 100% sin synch at all times (e.g due to WAN latency). My concern is that multiple trusts established this way may lead to replication inconsistency betweend master IPA server and it's replicas,especially in the case where the replica is seeing AD information in different stages of replication. My question: Does IPA cope with this scenario? Is it safe, and will it improve AD authentication performance (at least from the user point of view) to establish trust between each replica and the local domain controller in each given site? This topic was raised already in March on this list so please study archives for more details about site-awareness in SSSD. One thing I must note is that you seem to share a common misunderstanding of how trust to Active Directory is established. There is *no* need to 'establish an AD trust between the replica at each site and the local AD domain controller'. The trust is established once and for whole forest. Information about the trust is replicated to all IPA masters. In order to get them activated to *provide* access to already established trust you need to run 'ipa-adtrust-install' on each IPA master. However, you *don't* need to run 'ipa trust-add' again, and even if you ran it, it would fail because each of your local AD DCs are not a primary domain controllers for your forest root domain. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Can an Active Directory domain be the default domain?
In our newly-setup IPA environment, users can log in to RHEL clients with the username username@addomain. This works, but I've run into a problem with some RHEL 5 clients that are Apache servers -- the Apache UserDir mappings no longer work. Many of the users have web pages served from the public_html directory in their home directory. With our old NIS configuration, the URL is of the form http://hostname/~username. With the new IPA configuration, these URLs no longer work; the web pages are now found in http://hostname/~username@addomain. I can think of several ways to approach this problem, but my first thought is to have IPA recognize the AD domain as the default domain, so that our users could log in with username instead of username@addomain, and the existing URLs will work. Is this possible? I was looking at the auth_to_local setting in /etc/krb5.conf, but I couldn't figure out what to do with it. Thanks, David Guertin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] multihome - single interface?
On 2015-04-10 12:05, Petr Spacek wrote: On 10.4.2015 10:52, Janne Blomqvist wrote: On 2015-04-07 14:29, Martin Kosek wrote: On 04/05/2015 08:03 PM, Dmitri Pal wrote: On 04/05/2015 12:51 PM, Janelle wrote: Hello, Trying to find a way on a multi-homed server to force IPA and its related apps to listen on a specific interface. I can find all kinds of info saying the services listen on all interfaces by default so there must be a way? Thank you ~J Sounds familiar. I think there is a ticket open for that. This is the RFE: https://fedorahosted.org/freeipa/ticket/3338 Just in case anybody would like to help us extend FreeIPA installers :-) Hi, I have a related, or opposite really, problem. So I have configured IPA for a domain (say, ipa.example.org). Then I have a bunch of client machines that can join the domain etc. Fine so far. However, I also have another bunch of client machines on an internal network (with NAT access to the outside world). So for these I add another network interface on the ipa servers. So my ipa servers have two IP's and dns names, say, ipa1.ipa.example.org (some public IP) and ipa1.local (10.x.x.x IP). Now it doesn't work so well anymore for these clients, because the krb principals for the IPA server(s) are bound to the public name, so joining the domain fails (ipa1.local != ipa1.ipa.example.org). I can sort-of make it work by joining via the public interface (manually creating the machine accounts on the ipa server first, since otherwise it doesn't understand clientX.local dns names/IP's), but then obviously all communication goes via the NAT box which is a SPOF. So is there some reasonable way to make the above work? IMHO cleanest solution is to properly configure routing in your network to route your public IP range properly to the respective subnet instead of going through a NAT. Details depend on your network so I do not have exact steps for you, sorry. Thanks. So do you mean something like on each client machine in the NATed network I add special routes to the ipa servers? And by that the client machines would know that ipa1.ipa.example.org can be reached via ipa1.local instead of going via the default route (which is the NAT box)? -- Janne Blomqvist, D.Sc. (Tech.), Scientific Computing Specialist Aalto University School of Science, PHYS NBE +358503841576 || janne.blomqv...@aalto.fi -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can an Active Directory domain be the default domain?
On Mon, Apr 13, 2015 at 10:23:08AM -0400, David Guertin wrote: In our newly-setup IPA environment, users can log in to RHEL clients with the username username@addomain. This works, but I've run into a problem with some RHEL 5 clients that are Apache servers -- the Apache UserDir mappings no longer work. Many of the users have web pages served from the public_html directory in their home directory. With our old NIS configuration, the URL is of the form http://hostname/~username. With the new IPA configuration, these URLs no longer work; the web pages are now found in http://hostname/~username@addomain. I can think of several ways to approach this problem, but my first thought is to have IPA recognize the AD domain as the default domain, so that our users could log in with username instead of username@addomain, and the existing URLs will work. Is this possible? I was looking at the auth_to_local setting in /etc/krb5.conf, but I couldn't figure out what to do with it. Thanks, David Guertin Have you seen the default_domain_suffix option in sssd.conf? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] ipa-replica-prepare failing
Hi Rob, So you want to output of the command using pk12 with server cert and key? or with the ca chain in there too? Regards, David 2015-04-13 16:28 GMT+02:00 Rob Crittenden rcrit...@redhat.com: David Dejaeghere wrote: Hi, I get the same error when I use a pk12 with only the server certificate (and key) in it. Not sure what else I can try. I'd need to see the full output again. rob Regards, D 2015-04-11 0:23 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, I even tried the command using an export from the http service nss db, same issue. regarding SElinux: ausearch -m AVC -ts recent no matches Sending you the log personally. Ok, so the way the certs are imported is all the certs in the PKCS#12 file are loaded in, then marked as untrusted. certutil -O is executed against the server cert which prints out what the trust chain should be and those certs marked as trusted CA's. That part is working fine. Finally it makes another pass through the database to verify the chain. Looking at the output there are two certs with the subject CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US and different serial numbers. I wonder if this is confusing the cert loader. These certs are included in the PKCS#12 file (serial #0 and #1828629 AFAICT). I don't know which one is the right' one, or if there even is one. rob Regards, D 2015-04-10 17:03 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi Rob, Without the --http-pin the command will give a prompt to enter the password. Tried both. I am sending the output of the pk12util -l to you in another email. It holds the wildcard certificate and the godaddy bundle for as far as I can tell. I have to admit, I'm a bit stumped. (SEC_ERROR_LIBRARY_FAILURE) is a rather generic NSS error which can mean any number of things. It often means that the NSS database it is using is bad in some way but given that this is a temporary database created just for this purpose I doubt that's it. You may want to look for SELinux AVCs though: ausearch -m AVC -ts recent. At the point where it is blowing up, the PKCS#12 file has already been imported and IPA is walking through the results trying to ensure that the full cert trust chain is available. It does this by reading the certs out of the database, and at that point it's blowing up. The PKCS#12 output you sent me looks ok. I don't believe this is an issue with trust or missing parts of the chain. I created a simple PKCS#12 file and was able to prepare a replica using it, so AFAICT the code isn't completely broken. Can you provide the full output from ipa-replica-prepare? rob Regards, D 2015-04-09 21:39 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Sorry for the lack of details! You are indeed correct about the version its 4.1 The command I am using is this: ipa-replica-prepare ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com --http-cert-file /home/fedora/newcert.pk12 --dirsrv-cert-file /home/fedora/newcert.pk12 --ip-address 172.31.16.31 -v I was pretty sure a pin was required with those options as well. What do the PKCS#12 files look like: pk12util -l /home/fedora/newcert.pk12 rob Regards, D 2015-04-09 16:16 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com
Re: [Freeipa-users] ipa-replica-prepare failing
David Dejaeghere wrote: Hi, I get the same error when I use a pk12 with only the server certificate (and key) in it. Not sure what else I can try. I'd need to see the full output again. rob Regards, D 2015-04-11 0:23 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, I even tried the command using an export from the http service nss db, same issue. regarding SElinux: ausearch -m AVC -ts recent no matches Sending you the log personally. Ok, so the way the certs are imported is all the certs in the PKCS#12 file are loaded in, then marked as untrusted. certutil -O is executed against the server cert which prints out what the trust chain should be and those certs marked as trusted CA's. That part is working fine. Finally it makes another pass through the database to verify the chain. Looking at the output there are two certs with the subject CN=Go Daddy Root Certificate Authority - G2,O=GoDaddy.com, Inc.,L=Scottsdale,ST=Arizona,C=US and different serial numbers. I wonder if this is confusing the cert loader. These certs are included in the PKCS#12 file (serial #0 and #1828629 AFAICT). I don't know which one is the right' one, or if there even is one. rob Regards, D 2015-04-10 17:03 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi Rob, Without the --http-pin the command will give a prompt to enter the password. Tried both. I am sending the output of the pk12util -l to you in another email. It holds the wildcard certificate and the godaddy bundle for as far as I can tell. I have to admit, I'm a bit stumped. (SEC_ERROR_LIBRARY_FAILURE) is a rather generic NSS error which can mean any number of things. It often means that the NSS database it is using is bad in some way but given that this is a temporary database created just for this purpose I doubt that's it. You may want to look for SELinux AVCs though: ausearch -m AVC -ts recent. At the point where it is blowing up, the PKCS#12 file has already been imported and IPA is walking through the results trying to ensure that the full cert trust chain is available. It does this by reading the certs out of the database, and at that point it's blowing up. The PKCS#12 output you sent me looks ok. I don't believe this is an issue with trust or missing parts of the chain. I created a simple PKCS#12 file and was able to prepare a replica using it, so AFAICT the code isn't completely broken. Can you provide the full output from ipa-replica-prepare? rob Regards, D 2015-04-09 21:39 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com: David Dejaeghere wrote: Hi, Sorry for the lack of details! You are indeed correct about the version its 4.1 The command I am using is this: ipa-replica-prepare ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com http://ipa-r1.myobscureddomain.com --http-cert-file /home/fedora/newcert.pk12 --dirsrv-cert-file /home/fedora/newcert.pk12 --ip-address 172.31.16.31 -v I was pretty sure a pin was required with those options as well. What do the PKCS#12 files look like: pk12util -l /home/fedora/newcert.pk12 rob Regards, D 2015-04-09 16:16 GMT+02:00 Rob Crittenden rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com mailto:rcrit...@redhat.com
Re: [Freeipa-users] Can an Active Directory domain be the default domain?
On Mon, 13 Apr 2015, David Guertin wrote: In our newly-setup IPA environment, users can log in to RHEL clients with the username username@addomain. This works, but I've run into a problem with some RHEL 5 clients that are Apache servers -- the Apache UserDir mappings no longer work. Many of the users have web pages served from the public_html directory in their home directory. With our old NIS configuration, the URL is of the form http://hostname/~username. With the new IPA configuration, these URLs no longer work; the web pages are now found in http://hostname/~username@addomain. I can think of several ways to approach this problem, but my first thought is to have IPA recognize the AD domain as the default domain, so that our users could log in with username instead of username@addomain, and the existing URLs will work. Is this possible? I was looking at the auth_to_local setting in /etc/krb5.conf, but I couldn't figure out what to do with it. auth_to_local is for a different purpose. It is not possible to change SSSD to use default domain of AD forest root domain on IPA master because you'll break the compat tree and SSSD on IPA clients. Compat tree and extdom plugin are expecting to have normalized user names on IPA master. Additionally, compat tree is expecting normalized names to come from legacy clients, it is the only way we efficiently recognizing these requests to be done against AD users and not doing a search for every misnamed IPA user. Said that, you can set default domain in SSSD configuration on the legacy clients (RHEL 5) as then SSSD will ensure proper fully-qualified name will be sent towards compat tree and non-qualified name can be asked on the client (RHEL 5) side. However, this will only work in case you have a single AD domain in a forest. If you have more than one AD domain, you are out of luck. I'd suggest looking into mod_rewrite configuration to handle @addomain part in Apache configuration. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] CRON: Authentication service cannot retrieve authentication info
Hi, These problem appear randomly, sometime it still work even under heavy packet loss, some times would be like this. So its hard to catch. On Apr 13, 2015 3:22 PM, Jakub Hrozek jhro...@redhat.com wrote: On Mon, Apr 13, 2015 at 01:15:09PM +0800, Thomas Lau wrote: Hi all, We have cronjob which running on a FreeIPA LDAP user; When connection between IPA server and client having heavy packet loss, following error would occur: CRON[20637]: Authentication service cannot retrieve authentication info I have cache credentials and store password if offline enabled on sssd, how these problem would still happening? sssd.conf: cache_credentials = True krb5_store_password_if_offline = True Did the use log in at least once offline? You can verify if the password has been cached using the ldbsearch utility. It would be best to catch the occurence of the problem in logs. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Can an Active Directory domain be the default domain?
Said that, you can set default domain in SSSD configuration on the legacy clients (RHEL 5) as then SSSD will ensure proper fully-qualified name will be sent towards compat tree and non-qualified name can be asked on the client (RHEL 5) side. I was able to do this on RHEL 6/sssd 1.11 with default_domain_suffix = middlebury.edu, and it works great. But that command does not work with RHEL 5/sssd 1.5. Is there a comparable sssd.conf setting for older sssd versions? David Guertin -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Sudo rules w/ external users (RHEL7)
On Mon, 13 Apr 2015, Gould, Joshua wrote: On 4/13/15, 11:37 AM, Alexander Bokovoy aboko...@redhat.com wrote: Through external users' groups mechanism we use for any other AD users mapping in HBAC and SUDO. These are not local (not defined in IPA but defined on the host) groups and users but rather AD groups and users. ipa group-add --external gould_group_ext ipa group-add-member gould_group_ext --external=gould@test.osuwmc ipa group-add gould_group ipa group-add-member gould_group --groups=gould_group_ext And now make sudo rule that allows users of gould_group to run needed commands. SSSD will pull in all membership information for gould_group, including AD users. Just curious, but if we don¹t plan on using any IPA native users, could you skip the last two commands and add gould_group_ext to the sudo rule? No. gould_group_ext has no POSIX attributes and thus is not visible to sudo. I¹ve seen this same basic example used for HBAC, but it never was clear to me why the IPA group needed to be added if you¹re only concerned with AD users? Does it need to be added or do the examples include the IPA group because they assume that you¹ll be wanting to use a mix of AD and IPA users for HBAC and sudo? A schema IPA uses for storing group membership requires existence of an object in LDAP. AD users and groups don't exist in IPA LDAP and thus cannot be addressed directly. For doing this we create a real LDAP object which has reference to AD user/group's SID as a string. SSSD knows about this arrangement and properly pulls information from this LDAP object whenever it is encountered as a member of POSIX group. As result, you can see AD user or group as a member of a POSIX group but we need a helper object to allow this magic to work. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Sudo rules w/ external users (RHEL7)
On 4/13/15, 11:37 AM, Alexander Bokovoy aboko...@redhat.com wrote: Through external users' groups mechanism we use for any other AD users mapping in HBAC and SUDO. These are not local (not defined in IPA but defined on the host) groups and users but rather AD groups and users. ipa group-add --external gould_group_ext ipa group-add-member gould_group_ext --external=gould@test.osuwmc ipa group-add gould_group ipa group-add-member gould_group --groups=gould_group_ext And now make sudo rule that allows users of gould_group to run needed commands. SSSD will pull in all membership information for gould_group, including AD users. Just curious, but if we don¹t plan on using any IPA native users, could you skip the last two commands and add gould_group_ext to the sudo rule? I¹ve seen this same basic example used for HBAC, but it never was clear to me why the IPA group needed to be added if you¹re only concerned with AD users? Does it need to be added or do the examples include the IPA group because they assume that you¹ll be wanting to use a mix of AD and IPA users for HBAC and sudo? Joshua -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] user account without password
Hi Alex, Just because I gave up doesn't mean there isn't a way. Does your partitioning of local/domain users allow a domain user to run a service on a machine? I was trying to run an iPython notebook server as my regular user/domain account via systemd. Much of the data that the service needed access to resided on a multi-Terabyte NFS share, hence the desire to make it work with my domain account. IIRC, systemd was the thing choking on the domain user. Do you just manually create a local user with the same attributes as the domain user? (and in the case of the above use NFS with sec=host)? Thanks, Bryce -Original Message- From: Alexander Frolushkin [mailto:alexander.frolush...@megafon.ru] Sent: Sunday, April 12, 2015 9:27 PM To: Nordgren, Bryce L -FS; 'Martin Kosek'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] user account without password -Original Message- From: Nordgren, Bryce L -FS [mailto:bnordg...@fs.fed.us] Sent: Friday, April 10, 2015 9:27 PM To: Alexander Frolushkin (SIB); 'Martin Kosek'; freeipa-users@redhat.com Subject: RE: [Freeipa-users] user account without password Also, if such account will also exist locally (my case), it will not be controlled by HBAC rules - it can be a some kind of security trap... Pretty sure accounts should be either local or domain-wide, but not both. Could lead to strange and unforeseen side effects. Last I checked, only local accounts can run services. It may be advantageous to allow local accounts (which can run services) to have a representation in the domain, but the local accounts need to be scoped to the local machine (e.g., apache on server 1 is different than apache on server 2). At least that way, they could belong to the same groups domain accounts belong to. SSO certainly shouldn't work. Any access to shared storage should distinguish between same-named accounts on different machines. Alternatively, allowing domain accounts to run certain services also has some merit. (assuming the user has permissions to do so.) Just thinking into email. Bryce I have a long and positive experience using both local and IPA users with the same attributes, but without HBAC and without sudo way to obtain shell of such users. Default settings in nsswitch.conf and pam provides straight and clear systems behavior, for about three years. But I agree there can be case when such construction may lead to misbehavior and so on. We will try to avoid them. SSO not really the aim for us, we just need to made a environment where users must remember only one password to access all resources on unix/linux servers. Not trying to argue, just sharing some thoughts :) Alexander Информация в этом сообщении предназначена исключительно для конкретных лиц, которым она адресована. В сообщении может содержаться конфиденциальная информация, которая не может быть раскрыта или использована кем-либо, кроме адресатов. Если вы не адресат этого сообщения, то использование, переадресация, копирование или распространение содержания сообщения или его части незаконно и запрещено. Если Вы получили это сообщение ошибочно, пожалуйста, незамедлительно сообщите отправителю об этом и удалите со всем содержимым само сообщение и любые возможные его копии и приложения. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Sudo rules w/ external users (RHEL7)
I’ve looked at the docs and it looks as if I can specify an external user who can have sudo rights via IPA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/defining-sudorules.html#about-external-sudo The issue being that when I try to add my AD Trust user, it doesn’t allow the @ sign. (ex. gould@test.osuwmc). If I modify the sudo rule to allow all users, I can see that it allows my AD account sudo rights. $ sudo –l User gould@test.osuwmc may run the following commands on this host: (ALL : ALL) ALL How can I configure the rule to allow certain AD users to be able to execute certain sudo rules? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Sudo rules w/ external users (RHEL7)
On Mon, 13 Apr 2015, Gould, Joshua wrote: I’ve looked at the docs and it looks as if I can specify an external user who can have sudo rights via IPA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/defining-sudorules.html#about-external-sudo The issue being that when I try to add my AD Trust user, it doesn’t allow the @ sign. (ex. gould@test.osuwmc). If I modify the sudo rule to allow all users, I can see that it allows my AD account sudo rights. $ sudo –l User gould@test.osuwmc may run the following commands on this host: (ALL : ALL) ALL How can I configure the rule to allow certain AD users to be able to execute certain sudo rules? Through external users' groups mechanism we use for any other AD users mapping in HBAC and SUDO. These are not local (not defined in IPA but defined on the host) groups and users but rather AD groups and users. ipa group-add --external gould_group_ext ipa group-add-member gould_group_ext --external=gould@test.osuwmc ipa group-add gould_group ipa group-add-member gould_group --groups=gould_group_ext And now make sudo rule that allows users of gould_group to run needed commands. SSSD will pull in all membership information for gould_group, including AD users. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
