FreeIPA new network with DNS
by Jason Dunham
I am trying to set up a small office of software developers with FreeIPA.
My ipa-server-install fails with "DNS zone example.com. already exists in
DNS and is handled by servers foo1.myisp.net...".
We do have basic hosted dns for our few public facing servers but I want to
run an internal DNS on the LAN (and on the OpenVPN) to do name resolution.
We don't currently have any AD or Kerberos, this is basically a new company
with just a few people and a few workstations and will probably never grow
very large without massive infrastructure changes that would be way out of
scope for what I am trying to do.
I was going to set up the internal computers as
workstation1.internal.mycompany.com, workstation2.internal.mycompany.com,
etc. since my understanding is that I can't do it without a subdomain since
the primary domain DNS server already exists.
I am putting this on a new server with a fresh install of CentOS 8. The ipa
server is ipa.mycompany.com, or is it supposed to be
ipa.internal.mycompany.com? I was trying to use all the defaults when
calling ipa-server-install --setup-dns, but I don't really understand where
to tell it about the subdomain.
None of the many tutorials I have read seem to deal with my use case even
though it seems like something lots of people would want to do. Am I using
the right tool for this job? Am I just not finding the right web page that
makes it easy?
Can I run a small network with about 10 hosts and about 10 users on one
freeipa host? I also have a separate box for pfsense/openvpn and maybe I
could run a failover dns server on that, but I can't even get the main
server running.
Thanks in advance for any help with this.
4 years, 6 months
Commands ipa topologysegment-find/show are confusing
by Jesús Marín García
Hello everyone:
These days I have been doing a freeipa upgrade on a production cluster,
what requires to perform multiple operations on the cluster for doing it
without service interruption.
One of the tasks was to ensure the topology is a complete graph, where each
node have a connection with all the other nodes.
In order to get the current topology, the command is `ipa
topologysegment-find ca/domain`
But this is confusing since there is another command named `ipa
topologysegment-show...`.
A user could expect the following behaviour:
- topologysegment-show -> List all the elements, since "show" means you
want to see something in general terms.
- topologysegment-find -> List filtered elements by a given value, since
"find" means you want to see something concrete.
This is the same with other topics of the IPA command.
I think this sould be changed in order to be more clear. My proposal is as
follows:
- "topic"-list -> in order to list all the elements.
- "topic"-find -> in order to get certain elements filtered by a given
value.
- "topic"-detail or "topic"-describe -> in order to see the details of a
given element.
What do you think? Do you also find current commands confusing?
Thanks,
Regards
4 years, 6 months
Re: Single label domain usage
by Alexander Bokovoy
On ke, 16 loka 2019, Sven Ludwig via FreeIPA-users wrote:
>Hi Alexander,
>
>Thanks for the quick answer. As I am forced to use a non-email-product
>to write emails, please consider the following as "quoted properly" - i
>did my very best ;)
;) I'm reformatting the answers to fit the view, no problem.
>
>>>Are there any further problems with using single label domains
>>>currently or in the future?
>>There are problems when using forest trust to Active Directory. AD
>>simply doesn't support single label domains anymore.
>>
>>The real problem is that you might not know whether you would need to
>>integrate with AD at the time IPA is deployed. Realm cannot be changed
>>afterwards, so if you'd stuck with single label domain, you stuck
>>forever. With no reasonable migration path to export all data including
>>hashed keys for Kerberos principals to a different deployment (with
>>different realm), you would block yourself forever.
>
>This is always true if you decided to implement a certain thing on more
>then one instance. As you might already guessed, stuck is the situation
>I am in right now with thousands of clients deployed. We're stuck with
>centos ~7.6, where this check wasn't enforced to our environment or
>with continuously patching the package on our local mirrors.
There is https://pagure.io/freeipa/issue/8058 which was fixed recently
that should help adding new clients into existing single label
deployments. It is currently scheduled to next minor RHEL 7 update.
>
>>Another problem is that use of single label setup implies that you own
>>DNS TLD domain for it. E.g., for EXAMPLE realm, you need to own
>>.example. This is not going to work for all users unless they aren't
>>really integrating with global DNS system. But then it breaks badly
>>DNSSEC integrity as well as other DNS protection technologies. Although
>>something might work today, it will be broken tomorrow with
>>DNS-over-HTTPS, for example, where actual DNS name resolution is
>>performed outside your environment for everything, including your
>>internal hosts.
>>
>>What is possible technically in an isolated environment is not something
>>that should be promoted for general use. So we strongly discourage that.
>
>I totally get your point here. Because as thinking of the main driver
>into this, I'd rather expect a wizard which denies this option, but a
>proper work around using power shell or regedit. So from your point of
>you is patching the util.py the only way left to continue using your
>very own top level domain in isolated and non public environments?
See https://pagure.io/freeipa/issue/8058. It will not help for adding
new replicas, though. For that one I'm not expecting any change...
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
4 years, 6 months
Re: Single label domain usage
by Alexander Bokovoy
On ke, 16 loka 2019, Sven Ludwig via FreeIPA-users wrote:
>Hi @audience,
>
>I'd like to ask is there is a chance to continue using single label
>domains with freeipa. We learned the hard way that this feature was
>restricted to use. It cannot be bypassed by any command line option. I
>found that this all comes down to a check in the ipalib/util.py, which
>now counts the number of tokens in a list split by dots.
>
>It's easy to patch, but I am asking myself for the reason to disallow
>this without being able to overwrite this in command-line?
>
>Are there any further problems with using single label domains
>currently or in the future?
There are problems when using forest trust to Active Directory. AD
simply doesn't support single label domains anymore.
The real problem is that you might not know whether you would need to
integrate with AD at the time IPA is deployed. Realm cannot be changed
afterwards, so if you'd stuck with single label domain, you stuck
forever. With no reasonable migration path to export all data including
hashed keys for Kerberos principals to a different deployment (with
different realm), you would block yourself forever.
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
4 years, 6 months
Single label domain usage
by Sven Ludwig
Hi @audience,
I'd like to ask is there is a chance to continue using single label domains with freeipa. We learned the hard way that this feature was restricted to use. It cannot be bypassed by any command line option. I found that this all comes down to a check in the ipalib/util.py, which now counts the number of tokens in a list split by dots.
It's easy to patch, but I am asking myself for the reason to disallow this without being able to overwrite this in command-line?
Are there any further problems with using single label domains currently or in the future?
Regards,
Sven
4 years, 6 months
Re: How to make ipa root certificate available system wide
by Kevin Vasko
So I went back and read, reread, studied what you wrote and I think I’m following you. I’m really unfamiliar with certs and the tools around it so forgive the ignorance.
So what I ended up doing is spinning up a CentOS7 VM and installing everything on it, adding it to the FreeIPA realm etc. and followed your instructions/email.
I ran the
modutil -dbdir sql:./mozilla/firefox/9zd63dro.default/ -list
It returns the list of the PKCS #11 Modules like I listed in my previous email. However, it only showed a single item “NSS Internal PKCS #11 Module”.
To look at what keys it had I ran
certutil -d sql:./mozilla/firefox/9zd63dro.default/ -h “NSS Internal PKCS #11” -L
This seemed like it returned all of the system wide certs. Including my self signed internal lan cert from freeipa. Should it have? That’s where I’m getting confused with your comment in your email when you mentioned the p11-kit-proxy and where it’s coming from, how it was added (if needed) as you said it was providing all of the system wide certs?
At this point this is where things took a detour and I think it’s part of my confusion, which I think is unrelated, but I was using Firefox, all of the certs are there in the system based on the commands you showed. However, every time i would visit my http server Firefox would throw a
SEC_ERROR_REVOKED_CERTIFICATE
I pulled my hair out for 2 hours, deleting the .mozilla folder, recreating it, looking at certs, trying to manually copy certs into the cert db etc.
Until I got fed up and tried Chrome...i downloaded chrome installed it ran it, checked the certs db looked at the certs and verified my internal cert was listed just like firefox. I visited the http server in chrome and it worked perfectly. No changes, which I believe is what you would expect.
I then went and tried the same thing on Ubuntu. I know you mentioned that I have to add the certs manually as Ubuntu doesn’t have the same functionality. So I just manually added my ipa.crt to firefox and then got a
SEC_ERROR_REVOKED_CERTIFICATE
installed chrome on ubuntu machine and manually imported the ipa.crt into chrome, went to the http and chrome worked fine.
So now I have no idea where I’m getting this
SEC_ERROR_REVOKED_CERTIFICATE
So now on a freeipa realm joined host. It seems that
CentOS7 -
Firefox gets a - SEC_ERROR_REVOKED_CERTIFICATE
Chrome -
Works out of the box
Ubuntu 18.04 -
Firefox gets after manually adding cert- SEC_ERROR_REVOKED_CERTIFICATE
Chrome - works after manually adding the ipa.ca cert through GUI.
Is there some obvious reason why firefox would throw that error message but Chrome wouldn’t?
This stuff is making my head spin.
> On Thu, Oct 10, 2019 at 2:45 PM Kevin Vasko <kvasko(a)gmail.com> wrote:
>
> So you are saying that if the p11-kit-trust module is available it
> should be automatically adding the system wide trust store into the
> internal Firefox cert store?
>
> This is the out of my commands. I have the cert store thats create in
> my home directory.
>
> But there is no p11-kit-proxy do I have to add that myself? If so how
> do I do that?
>
> modutil -dbdir sql:/home/<username>/.mozilla/firefox/9zd63dro.default-release/
> -list
>
> Listing of PKCS #11 Modules
> -----------------------------------------------------------
> 1. NSS Internal PKCS #11 Module
> uri:
> pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.35
> slots: 2 slots attached
> status: loaded
>
> slot: NSS Internal Cryptographic Services
> token: NSS Generic Crypto Services
> uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
>
> slot: NSS User Private Key and Certificate Services
> token: NSS Certificate DB
> uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
> -----------------------------------------------------------
>
> I have the p11-kit-trust module.
>
> $ p11-kit list-modules
> p11-kit-trust: p11-kit-trust.so
> library-description: PKCS#11 Kit Trust Module
> library-manufacturer: PKCS#11 Kit
> library-version: 0.23
> token: System Trust
> manufacturer: PKCS#11 Kit
> model: p11-kit-trust
> serial-number: 1
> hardware-version: 0.23
> flags:
> write-protected
> token-initialized
>
>> On Thu, Oct 10, 2019 at 11:09 AM Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
>> On to, 10 loka 2019, Kevin Vasko wrote:
>>> Alexander,
>>> Unless I'm misunderstanding the information I don't think it will
>>> matter though because Firefox and Chrome use their own certificates
>>> stores. I found that information after I posted this question.
>>> Speaking specifically for firefox (and Chrome looks to be
>>> similar)...I'm concluding that why I'm not seeing it work is because
>>> of this...
>>> "Since Firefox does not use the operating system's certificate store
>>> by default, these CA certificates must be added in to Firefox using
>>> one of the following methods. " taken from here
>>> https://wiki.mozilla.org/CA/AddRootToFirefox
>> On RHEL/Fedora we do have some magic:
>> https://fedoraproject.org/wiki/Changes/NSSLoadP11KitModules
>> On my Fedora 30 system I have this for my Firefox profile:
>> $ modutil -dbdir sql:/home/abokovoy/.mozilla/firefox/$profile/ -list
>> Listing of PKCS #11 Modules
>> -----------------------------------------------------------
>> 1. NSS Internal PKCS #11 Module
>> uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46
>> slots: 2 slots attached
>> status: loaded
>> slot: NSS Internal Cryptographic Services
>> token: NSS Generic Crypto Services
>> uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
>> slot: NSS User Private Key and Certificate Services
>> token: NSS Certificate DB
>> uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
>> 2. mPollux
>> library name: /usr/lib64/libcryptoki.so
>> uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1
>> slots: There are no slots attached to this module
>> status: loaded
>> 3. p11-kit-proxy
>> library name: p11-kit-proxy.so
>> uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1
>> slots: There are no slots attached to this module
>> status: loaded
>> -----------------------------------------------------------
>> As you can see, there are three tokens attached. Number 1 is the NSS
>> internal 'token', that's how NSS database looks like typically. Number 2
>> is a crypto token inserted by the Fujitsu Finland Oy which is used for
>> my governmental ID operations through Firefox. Number three is the proxy
>> for system-wide crypto tokens in Fedora.
>> If I query that token separately, I can see a lot of certificates inside
>> Firefox NSS database. If I omit -h option, certificates from all tokens
>> get listed.
>> $ certutil -d sql:/home/abokovoy/.mozilla/firefox/$profile/ -h p11-kit-proxy -L |wc -l
>> 249
>> Exactly same story is with Chrome/Chromium, only that they use different
>> store than Firefox:
>> $ modutil -dbdir sql:/home/abokovoy/.pki/nssdb -list
>> Listing of PKCS #11 Modules
>> -----------------------------------------------------------
>> 1. NSS Internal PKCS #11 Module
>> uri: pkcs11:library-manufacturer=Mozilla%20Foundation;library-description=NSS%20Internal%20Crypto%20Services;library-version=3.46
>> slots: 2 slots attached
>> status: loaded
>> slot: NSS Internal Cryptographic Services
>> token: NSS Generic Crypto Services
>> uri: pkcs11:token=NSS%20Generic%20Crypto%20Services;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
>> slot: NSS User Private Key and Certificate Services
>> token: NSS Certificate DB
>> uri: pkcs11:token=NSS%20Certificate%20DB;manufacturer=Mozilla%20Foundation;serial=0000000000000000;model=NSS%203
>> 2. DigiSign PKCS#11 Module
>> library name: /usr/lib64/libcryptoki.so
>> uri: pkcs11:library-manufacturer=Fujitsu%20Finland%20Oy;library-description=mPollux%20DigiSign%20Client;library-version=0.1
>> slots: There are no slots attached to this module
>> status: loaded
>> 3. p11-kit-proxy
>> library name: p11-kit-proxy.so
>> uri: pkcs11:library-manufacturer=PKCS%2311%20Kit;library-description=PKCS%2311%20Kit%20Proxy%20Module;library-version=1.1
>> slots: There are no slots attached to this module
>> status: loaded
>> -----------------------------------------------------------
>> In past, people did manual work to pick up all the certs like
>> https://blog.xelnor.net/firefox-systemcerts/ but it is not really needed
>> anymore if you have p11-kit-proxy on your system. By default
>> p11-kit-proxy has two modules:
>> $ p11-kit list-modules
>> p11-kit-trust: p11-kit-trust.so
>> library-description: PKCS#11 Kit Trust Module
>> library-manufacturer: PKCS#11 Kit
>> library-version: 0.23
>> token: System Trust
>> manufacturer: PKCS#11 Kit
>> model: p11-kit-trust
>> serial-number: 1
>> hardware-version: 0.23
>> flags:
>> write-protected
>> token-initialized
>> token: Default Trust
>> manufacturer: PKCS#11 Kit
>> model: p11-kit-trust
>> serial-number: 1
>> hardware-version: 0.23
>> flags:
>> write-protected
>> token-initialized
>> opensc: opensc-pkcs11.so
>> library-description: OpenSC smartcard framework
>> library-manufacturer: OpenSC Project
>> library-version: 0.19
>> It is the first one that brings all the system-wide certificates into
>> NSS and other databases. For OpenSSL applications it can be brought in
>> via PKCS#11 engine support.
>>> So I at this point I don't think anything is wrong with
>>> ipa-install-client and it is performing correctly at this point adding
>>> it to the cert store. Given that the exception that you mentioned,
>>> that there is a difference in ipa-install-client adding it to the the
>>> NSS database on RHEL/Fedora/CentOS and not on the Ubuntu/Debian
>>> variants. However, I still don't think that will matter since
>>> Firefox/Chrome aren't reading either the NSS database or the crt
>>> bundle from what I understand.
>>> I'm going to keep digging to see if I find a solution for getting
>>> FF/Chrome to look at my certs and will post back on what I find.
>>> -Kevin
>>> On Thu, Oct 10, 2019 at 9:17 AM Alexander Bokovoy <abokovoy(a)redhat.com> wrote:
>>>> On to, 10 loka 2019, Kevin Vasko via FreeIPA-users wrote:
>>>>> I actually manually checked the system wide crt files on each
>>>>> distribution I'm using, Ubuntu, CentOS and RHEL6/7. In all cases my
>>>>> /etc/ipa/ca.crt did appear to be in the each of their respective *.crt
>>>>> files. That indicates to me that there isn't any problem with the
>>>>> ipa-install-client on any of the distributions like I originally
>>>>> thought. Rob it does look like Ubuntu is adding it to the
>>>>> /etc/ssl/certs/ca-certificates.crt with the ipa-install-client as I
>>>>> didn't do it manually on any of my systems, so it does appear they are
>>>>> doing it somehow.
>>>>> These are the locations I checked.
>>>>> "/etc/ssl/certs/ca-certificates.crt", //
>>>>> Debian/Ubuntu/Gentoo etc.
>>>>> "/etc/pki/tls/certs/ca-bundle.crt", // Fedora/RHEL 6
>>>>> "/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem", // CentOS/RHEL 7
>>>>> What appears to be the problem is (unless I'm mistaken) Firefox nor
>>>>> Chrome are using the system wide cert locations apparently and only
>>>>> using their own cert store. At least according to this article:
>>>>> https://thomas-leister.de/en/how-to-import-ca-root-certificate/
>>>> On RHEL/Fedora/CentOS we import system wide cert store automatically to
>>>> NSS databases through p11-kit.
>>>> On Ubuntu/Debian/Gentoo you need to do that manually.
>>>>> It kind of is backed up by this article on the Mozilla page.
>>>>> https://support.mozilla.org/en-US/kb/setting-certificate-authorities-firefox
>>>>> So based off of this information I'm going to have to manually add the
>>>>> root certificates to each Chrome and Firefox cert store on the client
>>>>> machines, which is a bummer.
>>>>> Sorry for the noise.
>>>>> On Thu, Oct 10, 2019 at 8:40 AM Rob Crittenden <rcritten(a)redhat.com> wrote:
>>>>>> Kevin Vasko via FreeIPA-users wrote:
>>>>>>> Kees Bakker,
>>>>>>> If it is, I'm certainly not seeing it done on Ubuntu 16.04 or Ubuntu
>>>>>>> 18.04 and based on Rob's comment it might not be done if I'm
>>>>>>> understanding him correctly.
>>>>>> Assuming I'm reading the code right it is not being executed on
>>>>>> Debian/Ubuntu. At least not in the source. It's possible it is patched
>>>>>> into the package in the distribution.
>>>>>> rob
>>>>>>> -Kevin
>>>>>>> On Thu, Oct 10, 2019 at 8:19 AM Kees Bakker via FreeIPA-users
>>>>>>> <freeipa-users(a)lists.fedorahosted.org> wrote:
>>>>>>>> On 10-10-19 14:35, Rob Crittenden via FreeIPA-users wrote
>>>>>>>>> Kevin Vasko via FreeIPA-users wrote:
>>>>>>>>>> How would I validate that certs are getting added properly on a CentOS machine system wide store?
>>>>>>>>>> I’m going to test it today to find out if this is a problem unique to Ubuntu/CentOS.
>>>>>>>>> On Fedora the chain is put into
>>>>>>>>> /etc/pki/ca-trust/source/anchors/ipa-ca.crt and update-ca-trust is executed.
>>>>>>>>> There is no Debian/Ubuntu equivalent in the upstream source (it's
>>>>>>>>> possible it is done in packaging). You could try something like:
>>>>>>>>> cp /etc/ipa/ca.crt /usr/local/share/ca-certificates/ipa-ca.crt
>>>>>>>>> update-ca-certificates
>>>>>>>> This is already done by ipa-client-install
>>>>>>>> _______________________________________________
>>>>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>>>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>>>> _______________________________________________
>>>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>>>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>>> _______________________________________________
>>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>>> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>>>>> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
>>>>> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
>>>>> List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho...
>>>> --
>>>> / Alexander Bokovoy
>>>> Sr. Principal Software Engineer
>>>> Security / Identity Management Engineering
>>>> Red Hat Limited, Finland
>> --
>> / Alexander Bokovoy
>> Sr. Principal Software Engineer
>> Security / Identity Management Engineering
>> Red Hat Limited, Finland
4 years, 6 months
Internal vs External CA
by Kristian Petersen
Hey y'all,
What are the pros and cons of using and external or internal CA for
FreeIPA/IdM? I am trying to decide which to do but having trouble finding
a lot of info about why I would want to do one or the other.
Thanks in advance!
--
Kristian Petersen
System Administrator
BYU Dept. of Chemistry and Biochemistry
4 years, 6 months
MFA authentication for some service only?
by William Kwan
Hi,
I ran some tests and was able to enable multi-factor authentication. What I have is a Fortinet firewall hooks up to LDAP on FreeIPA for VPN login. By turning on MFA for an user, when the user SSH to a Linux host, the MFA is required also. Is there anyway to have MFA on VPN but not on other services such as SSH?
ThanksW
4 years, 6 months
Re: Ipa user can't login via ssh
by Rob Crittenden
Please keep freeipa-users in the responses.
Elhamsadat Azarian wrote:
> Hi Rob
> I did it and i got this answer:
>
> Access granted : false
>
> What can i do now?
IPA ships with a default HBAC rule, allow_all, which allows all users to
authenticate on all hosts. I can only assume you've deleted or disabled
that, and that's fine.
But if you do then you need to create the set of rules to grant access
to hosts for the appropriate users.
To provide specific assistance you'd need to share a bit of internal
details, current HBAC rules, etc. It is understandable if you can't do that.
But basically you need to evaluate your HBAC rules to find out why this
user can't log into hosts. The user may be missing from a group, for
example.
rob
>
> On Mon, 14 Oct 2019, 18:07 Rob Crittenden, <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>> wrote:
>
> Elhamsadat Azarian wrote:
> > I tryed to add HBAC rules to my user but it said : some operation
> > failed. Users cannot be added when user category = all
>
> Adding list back.
>
> Try something like:
>
> ipa hbactest --user elham --service ssh --host <your host>
>
> There is an equivalent way to do it in the UI.
>
> rob
>
> >
> > On Wed, 9 Oct 2019, 17:19 Rob Crittenden, <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>
> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>> wrote:
> >
> > Kevin Vasko via FreeIPA-users wrote:
> > > Have you made sure your “elham” user has the correct permissions
> > to access the machines? Take a look in the UI at the
> > groups/permissions that user elham has. Take a look at your HBAC
> > rules as well. That would be my first recommendation to check
> if it
> > was me.
> >
> > Right, and the troubleshooting page suggests that (and
> increasing debug
> > logging).
> >
> > Please provide the output of the things you have already
> looked at.
> >
> > rob
> >
> > >
> > > -Kevin
> > >
> > >> On Oct 9, 2019, at 7:23 AM, Elhamsadat Azarian via
> FreeIPA-users
> > <freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> > <mailto:freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>>> wrote:
> > >>
> > >> ### Request for enhancement
> > >> as a Linux admin i want to login into my ipa client with a user
> > that is defined in ipa-server UI.
> > >>
> > >> ### Issue
> > >> I installed Ipa-server and an Ipa-client on CentOS7.6
> > >> I defined Internal DNS on ipa-server and i defined A and PTR
> > records for client on ipa-server.
> > >> now i can see my client in ipa-UI and i defined a user with
> name
> > "elham" and i expect that it can login into ipa-client.
> > >> when i login with root in ipa-client and i do sudo elham, it
> > works and kinit elham works too but
> > >> when i do ssh into ipa-client with this user, it show
> "Access denied"
> > >> i have errors with this context:
> > >> pam_reply : authentication failure to the client
> > >> pam_sss: authentication falure
> > >>
> > >> im tired of this issue. please help me if you know the
> solution.
> > >>
> > >> #### Steps to Reproduce
> > >> 1. define new user "elham" in ipa UI
> > >> 2. SSH to ipa-client with elham
> > >> 3. access denied
> > >>
> > >> #### Actual behavior
> > >> (what happens)
> > >>
> > >> #### Expected behavior
> > >> login into ipa-client successfully
> > >>
> > >> #### Version/Release/Distribution
> > >> ipa-server 4.6.5-11.el7
> > >> ipa-client 4.6.4-10.el7.centos.3
> > >> Log files and config files are added below:
> > >>
> > >>
> > >>
> > >> krb5.conf
> > >> ------------
> > >> #File modified by ipa-client-install
> > >>
> > >> includedir /etc/krb5.conf.d/
> > >> includedir /var/lib/sss/pubconf/krb5.include.d/
> > >>
> > >>
> > >> [logging]
> > >> default = FILE:/var/log/krb5libs.log
> > >> kdc = FILE:/var/log/krb5kdc.log
> > >> admin_server = FILE:/var/log/kadmind.log
> > >> [libdefaults]
> > >> default_realm = LSHS.DC
> > >> dns_lookup_realm = false
> > >> dns_lookup_kdc = false
> > >> rdns = false
> > >> ticket_lifetime = 24h
> > >> forwardable = yes
> > >> allow_weak_crypto = true
> > >> default_ccache_name = KEYRING:persistent:%{uid}
> > >>
> > >> [realms]
> > >> LSHS.DC = {
> > >> kdc = ipa-irvlt01.example.dc:88
> > >> admin_server = ipa-irvlt01.example.dc:749
> > >> default_domain = example.dc
> > >> }
> > >> [domain_realm]
> > >> .example.com <http://example.com> <http://example.com> =
> LSHS.DC
> > >> example.com <http://example.com> <http://example.com> = LSHS.DC
> > >> ############################################
> > >>
> > >>
> > >> sssd.conf
> > >> -------------
> > >> [domain/example.dc]
> > >>
> > >> cache_credentials = True
> > >> krb5_store_password_if_offline = True
> > >> ipa_domain = example.dc
> > >> id_provider = ipa
> > >> auth_provider = ipa
> > >> access_provider = ipa
> > >> ldap_tls_cacert = /etc/ipa/ca.crt
> > >> ipa_hostname = ipacli-irvlt01.example.dc
> > >> chpass_provider = ipa
> > >> dyndns_update = True
> > >> ipa_server = _srv_, ipa-irvlt01.example.dc
> > >> dyndns_iface = ens160
> > >> dns_discovery_domain = example.dc
> > >>
> > >> debug_level = 10
> > >> [sssd]
> > >> ########### AFTER IPA ###################
> > >> #services = nss, sudo, pam, ssh
> > >> services = nss, pam
> > >> config_file_version = 2
> > >> #########################################
> > >> domains = example.dc
> > >>
> > >> debug_level = 10
> > >> [nss]
> > >> homedir_substring = /home
> > >>
> > >> [pam]
> > >> debug_level = 10
> > >>
> > >> [sudo]
> > >>
> > >> [autofs]
> > >>
> > >> [ssh]
> > >>
> > >> [pac]
> > >>
> > >> [ifp]
> > >>
> > >> [secrets]
> > >>
> > >> [session_recording]
> > >>
> > >> ##########################################
> > >>
> > >>
> > >> _______________________________________________
> > >> FreeIPA-users mailing list --
> > freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> > <mailto:freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>>
> > >> To unsubscribe send an email to
> > freeipa-users-leave(a)lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>
> > <mailto:freeipa-users-leave@lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>>
> > >> Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > >> List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > >> List Archives:
> >
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > > _______________________________________________
> > > FreeIPA-users mailing list --
> freeipa-users(a)lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>
> > <mailto:freeipa-users@lists.fedorahosted.org
> <mailto:freeipa-users@lists.fedorahosted.org>>
> > > To unsubscribe send an email to
> > freeipa-users-leave(a)lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>
> > <mailto:freeipa-users-leave@lists.fedorahosted.org
> <mailto:freeipa-users-leave@lists.fedorahosted.org>>
> > > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines:
> > https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> >
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
> > >
> >
>
4 years, 6 months
/var/lib/sss/pubconf/known_hosts empty
by Vinícius Ferrão
Hello,
The /var/lib/sss/pubconf/known_hosts file is empty on a new installed FreeIPA server. I’ve already joined a machine to the domain but the file is still empty.
I can’t get it populated, already rebooted and/or restarted sssd without success.
Looking on the web I came across this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1574778
It is Fedora related, but it’s the same version that I’m running, since I’m on CentOS 7.6.
How can I check if is in fact this bug?
Here are some errors on sssd_ssh with debug_level = 9 enabled:
==> /var/log/sssd/sssd_ssh.log <==
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [sbus_remove_timeout] (0x2000): 0x55b758c55dc0
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [sbus_dispatch] (0x4000): dbus conn: 0x55b758c56e10
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [sbus_dispatch] (0x4000): Dispatching.
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 22 error message: Invalid argument
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [cache_req_common_dp_recv] (0x0040): CR #2: Data Provider Error: 3, 22, Invalid argument
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [cache_req_common_dp_recv] (0x0400): CR #2: Due to an error we will return cached data
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [cache_req_search_cache] (0x0400): CR #2: Looking up [hpclab01] in cache
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55b758c62d50
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55b758c62e10
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Running timer event 0x55b758c62d50 "ltdb_callback"
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 0x55b758c62e10 "ltdb_timeout"
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Ending timer event 0x55b758c62d50 "ltdb_callback"
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [sysdb_search_ssh_hosts] (0x0400): No such host
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [cache_req_search_cache] (0x0400): CR #2: Object [hpclab01] was not found in cache
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [cache_req_process_result] (0x0400): CR #2: Finished: Not found
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x55b758c60990
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x55b758c63960
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Running timer event 0x55b758c60990 "ltdb_callback"
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Destroying timer event 0x55b758c63960 "ltdb_timeout"
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ldb] (0x4000): Ending timer event 0x55b758c60990 "ltdb_callback"
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [sysdb_search_ssh_hosts] (0x0400): No such host
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [unique_filename_destructor] (0x2000): Unlinking [/var/lib/sss/pubconf/.known_hosts.yfSd2J]
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [unlink_dbg] (0x2000): File already removed: [/var/lib/sss/pubconf/.known_hosts.yfSd2J]
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [ssh_protocol_done] (0x4000): Sending reply: error [2]: No such file or directory
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x55b7572d88e0:hpclab01:hpclab01@cluster.iq.ufrj.br<mailto:hpclab01@cluster.iq.ufrj.br>]
==> /var/log/sssd/sssd_cluster.iq.ufrj.br.log <==
==> /var/log/sssd/sssd_ssh.log <==
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [client_recv] (0x0200): Client disconnected!
(Tue Oct 8 21:10:37 2019) [sssd[ssh]] [client_close_fn] (0x2000): Terminated client [0x55b758c4f940][18]
Installed versions:
[root@headnode ~]# rpm -qa | grep -i sssd
sssd-client-1.16.4-21.el7.x86_64
sssd-ldap-1.16.4-21.el7.x86_64
sssd-common-pac-1.16.4-21.el7.x86_64
sssd-dbus-1.16.4-21.el7.x86_64
sssd-ipa-1.16.4-21.el7.x86_64
sssd-proxy-1.16.4-21.el7.x86_64
sssd-common-1.16.4-21.el7.x86_64
sssd-ad-1.16.4-21.el7.x86_64
python-sssdconfig-1.16.4-21.el7.noarch
sssd-krb5-common-1.16.4-21.el7.x86_64
sssd-1.16.4-21.el7.x86_64
sssd-krb5-1.16.4-21.el7.x86_64
Thanks,
4 years, 6 months
