Re: [Freeipa-users] One kerberos realm, two dns zones and SSHFP records
On Wed, Mar 22, 2017 at 03:29:06PM -0400, Ranbir wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Hi Everyone, > > I'm using a fully updated CentOS 7.3 environment for two IPA servers. I > have one kerberos realm, one dns zone with the same name as the > kerberos realm and another dns zone with a different name. DNS is > managed by IPA. For the sake of this message: > > realm: REALM.IPA > dnszone1: realm.ipa > dnszone2: random.ipa > > When I join a server that's going into the realm.ipa dns zone to the > IPA domain, SSHFP records for that server get automatically created in > realm.ipa. But, when I do the same for a server going into the > random.ipa dns zone, the SSHFP aren't automatically created. I have to > do add the SSHFP records manually after the client install completes. > > Why are SSHFP records not added automatically for the second dns zone > and I how can I fix this situation? > > Thanks in advance. > > Ranbir > > > - -- > Ranbir > -BEGIN PGP SIGNATURE- > Version: GnuPG v2 > > iQIcBAEBCgAGBQJY0tCCAAoJEN7T/ly5z1dik3cP/0Xx0Vk0cIfbloYJuVb1ffMH > mJzKg3BaSEasWL3mJSsgPQS7CZWFi6PgBZLc79nwJhve1tAZC5+pMwVZwY9F7U9a > liZdK1l7a0agpDwnupISdih5PG6TGNEfVjHezKKwnDgjUWMOqak7BM3KIffjhNzc > SpuZHUDuY8QD2DeyO8iuuJjt+BUiWJ+Weh1OJq4UKWT68wALc/TbdtLi5OWlFtnV > rClTbOhPvm8I4Md3DT0vDdhKqPiUvBGPKgse7HZIN9G4W6/wpM3hU1+ETYgXWqIX > yRSK0rjjxfrWKIqRUB1sCKLlkdd+wMaRa/uCnRgvRhYjYUrwyPaH11N41lvE7zUz > ccJnaZXkDcIWW9wkAQxx3XXx5vHR33VTS13nkZv4QsHSoJOXcqrsr+Q1r28WmLcZ > wb3osINWIEmFCX6knZVRZLDhAefHz+FVsJwzsh6iCdqar+LzFvR0hRUJ0Fepxs8M > bkKEZ3LztTtDssX+AO7CqkMZSQ5DHiT9Yo1gHXr2zTEt3qzxyuE0GjMyXzBWyMV4 > TpOXoRVQMUvEEV2ecpEATBEKghqXOMqhSeGAObfdlEKADTt11u8ONxwutFYPxybD > Sxfd6yvg2/QvB8GYgLMkENuJWdwbFYrlb3GQ04TKjcW6TklcRyjsI8x/Wg3LjofQ > AEtlIGyrGau9jPaeHYwd > =mJn4 > -END PGP SIGNATURE- > > -- > 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 Hello Ranbir, are other records (A, , PTR, ...) created for the client in random.ipa and just SSHFP missing? Is the domain random.ipa properly delegated? Is sshd installed and keys generated on client in random.ipa? -- David Kupka signature.asc Description: PGP signature -- 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 domain level is 1, so replica prepare fails (new installation)
On Wed, Mar 22, 2017 at 04:38:58AM +, Z D wrote: > Hallo, I have a problem to prepare the replica. > > Environment: > > OS: Newly installed EL7.3 > > IPA Server: Newly installed ipa-server 4.4.0 > > The error: > > # ipa-replica-prepare > Replica creation using 'ipa-replica-prepare' to generate replica file > is supported only in 0-level IPA domain. > The current IPA domain level is 1 and thus the replica must > be created by promoting an existing IPA client. > To set up a replica use the following procedure: > 1.) set up a client on the host using 'ipa-client-install' > 2.) promote the client to replica running 'ipa-replica-install' > *without* replica file specified > 'ipa-replica-prepare' is allowed only in domain level 0 > The ipa-replica-prepare command failed. > > Any explanation for this and possible resolution, thanks, Zarko > > -- > 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 You can also look into RHEL documentation: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/creating-the-replica.html -- David Kupka signature.asc Description: PGP signature -- 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 domain level is 1, so replica prepare fails (new installation)
On Wed, Mar 22, 2017 at 04:38:58AM +, Z D wrote: > Hallo, I have a problem to prepare the replica. > > Environment: > > OS: Newly installed EL7.3 > > IPA Server: Newly installed ipa-server 4.4.0 > > The error: > > # ipa-replica-prepare > Replica creation using 'ipa-replica-prepare' to generate replica file > is supported only in 0-level IPA domain. > The current IPA domain level is 1 and thus the replica must > be created by promoting an existing IPA client. > To set up a replica use the following procedure: > 1.) set up a client on the host using 'ipa-client-install' > 2.) promote the client to replica running 'ipa-replica-install' > *without* replica file specified > 'ipa-replica-prepare' is allowed only in domain level 0 > The ipa-replica-prepare command failed. > > Any explanation for this and possible resolution, thanks, Zarko > > -- > 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 Hello Zarko, as already described in the output you've posted ipa-replica-prepare is no longer used when domain level is above 0. Since domain level 1 new replica is first joined to FreeIPA domain as client using ipa-client-install and then promoted to replica using ipa-replica-install. You can find out more about Replica Promotion on design page [1]. [1] https://www.freeipa.org/page/V4/Replica_Promotion -- David Kupka signature.asc Description: PGP signature -- 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] Original master lost, cannot create additional CA clones
00 OK > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 > RESPONSE HEADER: Date: Fri, 17 Mar 2017 15:50:34 GMT > RESPONSE HEADER: Connection: close > Exception in SecurityDomainLoginPanel(): java.lang.Exception: Invalid > clone_uri > ERROR: ConfigureSubCA: SecurityDomainLoginPanel() failure > ERROR: unable to create CA > > ### > > 2017-03-17T15:50:35Z DEBUG stderr=java.lang.Exception: Invalid clone_uri > at ConfigureCA.SecurityDomainLoginPanel(ConfigureCA.java:392) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1179) > at ConfigureCA.main(ConfigureCA.java:1663) > > > In /var/log/pki-ca/debug, I see: > > Could not get or build CA chain. Error > java.security.cert.CertificateException: Certificate is not a PKCS #11 > certificate > at > com.netscape.ca.CertificateAuthority.initSigUnit(CertificateAuthority.java:1285) > at > com.netscape.ca.CertificateAuthority.init(CertificateAuthority.java:262) > > > In /var/log/pki-ca/catalina.out I see: > > CMS Warning: FAILURE: Cannot build CA chain. Error > java.security.cert.CertificateException: Certificate is not a PKCS #11 > certificate|FAILURE: authz instance DirAclAuthz initialization failed and > skipped, error=Property internaldb.ldapconn.port missing value| > > > I have tried deploying a new replica to freshly installed systems, and the > same problem occurs. I have backups from when IPA was first installed, if any > config files or certificates need to be brought back. I can provide further > log excerpts if needed. > > Thank you in advance, > Paul Brennan > > -- > 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 Hello Paul, is there a reason you run ipa-replica-install with --skip-conncheck option? Does it fail with the same error when you run with connection check? There might be some closed ports on ipasrv201's firewall that cause this fail and connection check would discover this. But it's just my wild guess. -- David Kupka signature.asc Description: PGP signature -- 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] ldap connector from IIQ to ipa
On Mon, Mar 20, 2017 at 05:23:31PM +0100, Iulian Roman wrote: > Hello, > > We do plan to integrate IPA with IdentityIQ (sailpoint) for user > provisioning. Because IPA does abstract all the ldap commands via new set > of commands and APIs, i am not sure if the standard ldap connector is the > right option and if it is supported ( taking into consideration that a > simple user creation does update/create more ldap containers). > > Could you please clarify if updating IPA via standard ldap commands is > supported but not necessarily a best practice or it is an absolute NO ? > > Thank You ! > -- > 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 Hello! We have staging area for this purpose. You can create and update user entries there and once the entry is complete you can call stageuser-activate to create user entry with using values from stageuser entry. You can find description of the feature and examples on design page [1]. [1] http://www.freeipa.org/page/V4/User_Life-Cycle_Management -- David Kupka signature.asc Description: PGP signature -- 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] Use SQLite format NSS database?
On Sat, Mar 18, 2017 at 11:58:35AM -0500, Ian Pilcher wrote: > Can IPA 4.4 (on CentOS 7) use a SQLite format NSS database in > /etc/httpd/alias? > > I would presumably have to prepend "sql:" to the NSSCertificateDatabase > setting in nss.conf. > > Anything else? > > -- > > Ian Pilcher arequip...@gmail.com > "I grew up before Mark Zuckerberg invented friendship" > > > -- > 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 Hello Ian, I'm not sure but I guess there will be surprises on the way. First of all you need to migrate the DB to SQL format (1). Then you will have two DBs in alias directory one in old and one in new format. This is probably not what you want because then you can easily end up with two different sets of certificates and hard to find errors. So it's probably better to remove old DB (cert8.db, key3.db and secmod.db). But then you'll break ipa-certupdate, ipa-server-certinstall and probably others because they use the old format. Prefixing 'sql:' to HTTPD_ALIAS_DIR in /usr/lib/ptyhon2.7/site-packages/ipaplatform/base/paths.py might help but I never tried. Generally I would not recommend touching this on production system. Why do you want to change the database format? (1) certutil -d sql:HTTPD_ALIAS_DIR --upgrade-merge --source-dir HTTPD_ALIAS_DIR --upgrade-id 1 -- David Kupka signature.asc Description: PGP signature -- 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] Options for existing CA/DNS infrastructure
On Sun, Mar 12, 2017 at 10:47:02PM -0400, Rob Foehl wrote: > I'm looking at deploying FreeIPA in a few environments with substantial DNS > and/or CA infrastructure, and have some choices to make... > > How much trouble will I have if FreeIPA is delegated a zone like > ipa.example.com with all clients in example.com or other children? (No > overlap with AD-managed zones, but in at least one case autodiscovery won't > be possible due to mixed clients in the parent zone.) > > What's the best way to play nice with existing PKI -- generate a CA CSR at > installation time and sign that? Is there any provision for automatically > renewing these certs, say if the external CA were to be subsumed by a > dedicated Dogtag instance? > > Advice and experience appreciated, before I paint myself into a corner > somewhere... Thanks! > > -Rob > > -- > 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 Hello Rob, FreeIPA can be deployed in environment with existing DNS and/or CA server. IIRC you have following options: - regarding DNS: -- Delegate DNS zone for FreeIPA. It will then manage the zone and add records there. Obviously, it will not add records for clients in other zones. -- Don't setup DNS in FreeIPA and keep managing all records in your current DNS server. There's plan to integrate with external DNS servers [1] but nothing was done yet. - regarding CA: -- install CA-less FreeIPA - you need to issue certificates for HTTPD and 389-DS with your certificate server and provide those when installing FreeIPA server -- install FreeIPA with CA certificate signed with external CA. Use --external-ca option. The installation will be interupted to let you sign generated CSR. FreeIPA will then issue all needed certificates. -- install FreeIPA with self-signed CA certificate. This is default but then you need to distribute the certificate to all clients. Certmonger [2] is configured during ipa-server-install to track and renew certificates. [1] https://www.freeipa.org/page/V4/External_DNS_integration_with_installer [2] https://pagure.io/certmonger -- David Kupka signature.asc Description: PGP signature -- 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] Freeipa 4.4 creating users with expiration
On Fri, Mar 03, 2017 at 08:44:45PM +0530, Rakesh Rajasekharan wrote: > Hello, > > Am using Freeipa 4.4 version . > > I would like to create few users only valid for few days or months. So,is > there a way to create few users with a preset expiration or auto lock those > accounts after a few days > > Thanks > Rakesh > -- > 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 Hello Rhakesh, AFAIK there's no mechanism to Lock the user account after period of time or at specified time. You need to call "ipa user-disable LOGIN" manually. You can file ticket and describe your use-case here: https://pagure.io/freeipa/new_issue -- David Kupka signature.asc Description: PGP signature -- 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] Looking for instructions on one way subtree sync IPA->IPA
On Tue, Feb 21, 2017 at 10:27:40AM +, Paris, Dan wrote: > Hi FreeIPA-users, > > My colleague Nick Piper emailed > previously<https://www.redhat.com/archives/freeipa-users/2017-February/msg00121.html> > regarding the subject matter. > > We are still attempting to find a solution that meets our requirements and > are considering manually building an ldif file to import into our master IdM > server. In the reply to our original query Alexander Bokovoy mentioned: "In > short, there is no support for IPA-IPA trust or replication. There are many > reasons for that, including some complex technical issues on how this could > be reliably working." Would you be able to provide some detail around these > technical issues and provide some guidance as to if exporting an ldif file > would meet our needs? > > Thanks in advance, > Dan > > Dan Paris | Leading Engineer > 250 Brook Drive, Reading, RG2 6UA | United Kingdom > M: +44 7920783573 > dan.pa...@cgi.com<mailto:simon.hed...@logica.com> | > www.cgi.com<http://www.logica.comregistered/> > Registered in England & Wales (registered number 947968) > Registered Office: 250 Brook Drive, Green Park, Reading RG2 6UA, United > Kingdom > -- > 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 Hi Dan! The biggest missing part on the way to FreeIPA-FreeIPA trust is the Global Catalog [1]. There might be (and probably are) other parts that FreeIPA lacks but I don't know the details. Regarding using ldif for synchronization. I don't think that's good idea for several reasons: 1) It will be hard and error prone to keep the data in sync. Even in case you would claim that corporate FreeIPA is authoritative source and all changes made in project FreeIPA will be lost you would need to periodically export, optionally compare and replace potentionally huge number of entries (users, groups, sudo rules, HBAC rules, ...). 2) To be able to obtain Kerberos ticket for user you would need to copy also Kerberos master key which is used to encrypt keys for users. This is quite sensitive material. By the way have you considered having just single FreeIPA deployment as I proposed in [2]? Why is separate deployment of FreeIPA for the project required? [1] https://technet.microsoft.com/en-us/library/cc730749(v=ws.11).aspx [2] https://www.redhat.com/archives/freeipa-users/2017-February/msg00136.html -- David Kupka signature.asc Description: PGP signature -- 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] sysaccounts max length
On Sat, Feb 18, 2017 at 03:06:21PM +0100, Matt . wrote: > Hi Guys, > > Does anyone know what the max length is for a sysaccount username is ? > > Thanks, > > Matt > > -- > 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 Hello! From man 8 useradd: Usernames may only be up to 32 characters long. -- David Kupka signature.asc Description: PGP signature -- 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] How to change kerberos key lifetime?
On Thu, Feb 16, 2017 at 06:05:48PM -0500, William Muriithi wrote: > David > > > > > > The fact that your desktops are using SSSD changes the situation > > dramatically. > > > > SSSD (with ipa or krb5 provider) obtains ticket for user when he is > > logging-in. > > And can be configured to renew the ticket for the user until the ticket > > renew > > life time expires. > > > > Given this you can keep ticket life time reasonable short (~1 day) set > > ticket > > renewable life time to longer period (~2 weeks) and maintain reasonable > > security level without negative impact on user's daily work. > > > > Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options > > in sssd-krb5 man page. > > > Thanks a lot. I did actually end up using this. Will wait for a > couple of days and see if anybody if the situation is better and > update you. > > Curious though, why isn't renewal interval setup by default? Is there > a negative consequence of having SSSD renewing tickets by default? I > can't think of any and hence a bit lost on explaining the default > setup > > -- > Regards, > William Honestly, I don't know why krb5_renew_interval isn't set by default. My wild guess would be that in typical SSSD deployment user logs-in in the begining of work day, SSSD gets ticket that last for a day for him and he logs-out in the end of the workday (after 8~10 hours). So there's no need to refresh it. But feel free to open a ticket for SSSD [1] and describe you use case. I don't know SSSD that well and maybe there's no reason against setting it by default. [1] https://fedorahosted.org/sssd/newticket -- David Kupka signature.asc Description: PGP signature -- 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] How to change kerberos key lifetime?
On Thu, Feb 16, 2017 at 07:54:47AM -0500, William Muriithi wrote: > Morning David, > > Thank you very much for your help. > > > first you're mentioning "key expiry" but if I understand correctly you're > > interested in "ticket lifetime". > Yes, want to increase ticket lifetime. > > > > As mentioned here [1] the ticket lifetime is the minimum of 4 values: > > 1) maxlife for the user principal > > 2) maxlife for the service [principal] > > 3) max_life in the kdc.conf > > 4) requested lifetime in the ticket request > > > > You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in > > [libdefaults] in /etc/krb5.conf on client). > > > > To increase 2) you need to change maxlife for krbtgt service. There're two > > ways > > this ca be done: > > a) modifying krbMaxTicketLife attribute in > > krbPrincipalName=krbtgt/example@example.org,cn=EXAMPLE.ORG,cn=kerberos,dc=example,dc=org > > b) using kadmin.local: > > # kadmin.local > > Authenticating as principal admin/ad...@example.org > > : modprinc -maxlife 10day krbtgt/EXAMPLE.ORG > > Principal "krbtgt/example@example.org" modified. > > : exit > > Will try 2 b and see how it goes > > > > > To increase 3) you need to change 'max_life' in > > /var/kerberos/krb5kdc/kdc.conf > > and restart krb5kdc service. > > > > okay, wasn't actually aware of this. Will look at it > > > But generally I don't think it's a good idea to have such long tickets. > > Would > > it make sense in your use case to deploy SSSD on user systems to handle > > Kerberos tickets for them? > > > I am actually using SSSD on all the systems, even the desktops. I > agree the changes above aren't ideal and would prefer to get SSSD > working well. Where would like to avoid this error showing around > every 12 hours. > > antimony: Could not chdir to home directory /home/william: Key has expired > > > Regards, > William Hello William! The fact that your desktops are using SSSD changes the situation dramatically. SSSD (with ipa or krb5 provider) obtains ticket for user when he is logging-in. And can be configured to renew the ticket for the user until the ticket renew life time expires. Given this you can keep ticket life time reasonable short (~1 day) set ticket renewable life time to longer period (~2 weeks) and maintain reasonable security level without negative impact on user's daily work. Look for krb5_renew_interval, krb5_lifetime, krb5_renewable_lifetime options in sssd-krb5 man page. -- David Kupka signature.asc Description: PGP signature -- 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] How to change kerberos key lifetime?
On Wed, Feb 15, 2017 at 02:13:04PM -0500, William Muriithi wrote: > Hello > > We are currently mostly using RHEL 6 on the clients but IPA is on RHEL > 7.3. I am using Kerberos to authenticate NFS mount and its working > fine. However, there is a lot of users who are complaining that its > causing too much problems. They are all related to key expiry > > > I have looked at how to rectify this and noticed that the only > solution with RHEL 6 is to increase the time the key is valid. > However, it hasn't worked, the key lifetime remains a day and maximum > lifetime of 7 days. > > These are the changes I have made so far: > > Changed the policy on IPA: > > [root@lithium ~]# ipa krbtpolicy-show > Max life: 15552000 > Max renew: 25552000 > [root@lithium ~]# > > > Changed kerberos configuration: > > [libdefaults] > default_realm = ENG.EXAMPLE.COM > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 4320h > forwardable = yes > udp_preference_limit = 0 > > > Changed sssd configurations: > > [domain/eng.example.com] > > krb5_renewable_lifetime = 180d > krb5_renew_interval = 3600 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = eng.example.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = platinum.eng.example.com > chpass_provider = ipa > ipa_dyndns_update = True > ipa_server = _srv_, lithium.eng.example.com > ldap_tls_cacert = /etc/ipa/ca.crt > autofs_provider = ipa > ipa_automount_location = default > [sssd] > services = nss, sudo, pam, autofs, ssh > > domains = eng.example.com > [nss] > homedir_substring = /home > > None have lead to any difference as seem below. What would I be missing? > > Ticket cache: FILE:/tmp/krb5cc_782_L8aH9N > Default principal: will...@eng.example.com > > Valid starting ExpiresService principal > 02/15/17 13:17:11 02/22/17 13:17:11 krbtgt/eng.example@eng.example.com > renew until 03/01/17 13:17:11 > > Regards, > William > > -- > 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 Hello William, first you're mantioning "key expiry" but if I understand corectly you're interested in "ticket lifetime". As mentioned here [1] the ticket lifetime is the minimum of 4 values: 1) maxlife for the user principal 2) maxlife for the service [principal] 3) max_life in the kdc.conf 4) requested lifetime in the ticket request You've already done 1) (ipa krbtpolicy) and 4) (ticket_lifetime in [libdefaults] in /etc/krb5.conf on client). To increase 2) you need to change maxlife for krbtgt service. There're two ways this ca be done: a) modifying krbMaxTicketLife attribute in krbPrincipalName=krbtgt/example@example.org,cn=EXAMPLE.ORG,cn=kerberos,dc=example,dc=org b) using kadmin.local: # kadmin.local Authenticating as principal admin/ad...@example.org : modprinc -maxlife 10day krbtgt/EXAMPLE.ORG Principal "krbtgt/example@example.org" modified. : exit To increase 3) you need to change 'max_life' in /var/kerberos/krb5kdc/kdc.conf and restart krb5kdc service. But generally I don't think it's a good idea to have such long tickets. Would it make sense in your use case to deploy SSSD on user systems to handle Kerberos tickets for them? [1] http://mailman.mit.edu/pipermail/kerberos/2009-February/014520.html -- David Kupka signature.asc Description: PGP signature -- 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] Looking for instructions on one way subtree sync IPA->IPA
| > > | |^ | | > > | |Project + > > | ++ | user1 can own > > | | processes here > > | | > > | | > > | | > > | | > > | +++-+ +-+ ++ | > > | ||| | | | || | > > | | IPA|| Linux | | Linux | | App using | | > > | ||| OS | | OS | | LDAP | | > > | +++-+ +-+ ++ | > > | | > > |^ | > > || | > > | Wider Enterprise Estate | > > +|-+ > > | > > | > > user1 details mastered here > > > > > > If 'Enterprise' IPA was instead Active Directory, I believe the above > could be achieved with a One way Trust? > > We have an additional aim to be able to set authorisation rules in the > Project IPA (e.g., putting the Enterprise IPA users into groups where > the groups are managed in Project IPA.) > > Thanks, > > Nick > > -- > 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 Hi Nick, I might be missing something but I would say that the Project IPA is not necessary in the desribed scenario. You can create accounts for all the users involved in Project in Enterprise IPA and assign them to Project group. You can also enroll all Project hosts to Enterprise IPA and add them to Project hostgroup. Then you can use HBAC rules [1] to: * disable the default allow_all rule * allow everyone in Project IPA to acces Project hostgroup * allow all but Project group to access Any host Employees that are also part of other group will be still able to access everything. Contractors will be only in Project group and won't be able to access your Enterprise environment. Of course, unless this is against your company policy... [1] http://www.freeipa.org/page/Howto/HBAC_and_allow_all -- David Kupka signature.asc Description: PGP signature -- 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] client in many IPA domains
On Fri, Feb 03, 2017 at 02:04:55PM -0200, Raul Dias wrote: > Hello, > > Can ipa-client (e.g., anotebook) be in more than one realm? e.g. depending > on the network where it is connected. > > -rsd > > -- > 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 Hello! It depends what are you expectation about features that will be available on such client. If you just want to be able to obtain Kerberos ticket for a user on the client it will work even without FreeIPA (assuming DNS records for Kerberos are in place). Enrolling the client to two FreeIPA domains is theoretically doable but: a) would require some experimentation and manual tinkering, b) may bring security issues (e.g. sharing the same Kerberos key with both domains), c) will likely result in weird behavior, d) is definitelly not supported nor encouraged. -- David Kupka signature.asc Description: PGP signature -- 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] manually apply patches from upstream
On 20/01/17 06:23, Jeff Clay wrote: I’m using Centos 7 and have installed 4.4.0-14, however I’m using Google Cloud and needing some updates that have already been made upstream at https://fedorahosted.org/freeipa/ticket/5814 <https://fedorahosted.org/freeipa/ticket/5814> I have downloaded the diffs from the 3 commits to the 4.4 branch. Searching my system for the proper directories, I found that many of the files (like replicainstall.py) can be found in a sub dir of of /usr/lib/python2.7/site-packages/ while other parts can be found in /usr/sbin/ I’m just wondering what is the best and proper way for me to apply those code changes? Thanks. Hello Jeff, modifying package-installed "binaries" or "libraries" on production system is really bad idea. You may easily end up with system broken in numerous ways. Proper way is to get CentOS downstream git clone [1] add the desired patches and build your own package. [1] https://git.centos.org/commit/rpms!ipa.git -- David Kupka -- 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] Limit regular user access only to self service portal
On 17/01/17 16:23, Georgijs Radovs wrote: Hello everyone! Is it possible to configure Sef-service permissions in FreeIPA in a way, so that, when regular users log in, they don't have read access to other FreeIPA sections like "Policy", "Authentication", "IPA Server"...? My goal is - when user logs in Self-service portal, he sees only his user account in "Identity" tab, no other tabs like "Policy" or "Authentication" and can read and write only to his profile. Basically, I want to limit user to his account only, so he does not see information about other accounts. Hello, by default user without any added roles can see "Users" and "OTP Tokens" tabs and is able to read other users and modify only his attributes. You can find permissions that affects reading user attributes in IPA Server->Role Based Access Control->Permissions (eg. System: Read User Addressbook Attributes) and change "Bind rule type" from all to "permission". But be aware that modifying the permissions may result in SSSD being unable to resolve users unless you add those permissions to hosts (SSSD always uses host principal in FreeIPA deployment). -- David Kupka -- 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] FreeIPA 4.4 plugin migration path
On 17/01/17 12:16, Peter Fern wrote: On 17/01/17 21:48, David Kupka wrote: Ok, your plugin is not really a plugin but that should not be a problem. To make it work: 1) replace "from ipalib.plugins.user import user" with "from ipaserver.plugins.user import user" 2) make sure "user_mailalternateaddress.py" is also in ipaserver/plugins/ 3) restart httpd Thank you, that gets the web UI working as expected, but I seem to be missing the CLI switch. That is probably caused by client API schema cache that was also added in 4.4. Once the schema is downloaded and stored in cache it's validity is not checked for the next hour. You can either force the check to be performed immediately: $ ipa -v -e force_schema_check=1 user-add --help or remove the cache: $ rm -r ~/.cache/ipa/ You can find more about this feature and related changes on its design page [1] I'm also adding an objectclass to the default userobjectclasses (and updating existing users) in my install script, but it looks like maybe I can use the 'updates' mechanism for this, is that right? If so, is that mechanism documented anywhere? Adding objectclass or generally any attribute to many entries (users tends to be numerous) may take really really long and is not a good idea. It's better to add such objectclass on demand when the attribute is added to the entry for the first time. But I agree with Alexander, in longer run it would be much better if you create and package proper plugin. [1] http://www.freeipa.org/page/V4/API_Compatiblity -- David Kupka -- 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] FreeIPA 4.4 plugin migration path
On 17/01/17 11:30, Peter Fern wrote: On 17/01/17 20:39, David Kupka wrote: in 4.4 we split the plugins to the server and client plugins. Simple plugins (like server plugin) needs to exist only on server and all what is needed is to move it from ipalib/plugins to ipaserver/plugins. But if commands in your plugin define interactive_prompt_callback (like dns plugin) or forward (like vault plugin) you will need to split the client and server part of the plugin. Hi David, I tried that, but it didn't end well. My plugin is quite simple, just adds an attribute to the user model and UI/CLI extensions to manage it. However it looks like plugin structure has changed (I see @register decorators(?) and such), and ipalib.user no longer exists. My old plugin is available here: https://github.com/pdf/freeipa-user-mailalternateaddress/blob/master/user_mailalternateaddress.py Unfortunately Python is not a language I'm particularly familiar, so I've not come across some of the patterns used in the new plugins, and any pointers would be appreciated. Thanks, Pete Ok, your plugin is not really a plugin but that should not be a problem. To make it work: 1) replace "from ipalib.plugins.user import user" with "from ipaserver.plugins.user import user" 2) make sure "user_mailalternateaddress.py" is also in ipaserver/plugins/ 3) restart httpd -- David Kupka -- 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] FreeIPA 4.4 plugin migration path
On 17/01/17 10:10, Peter Fern wrote: Hello all, It appears there have been quite a few changes to the FreeIPA plugin infrastructure in the 4.4 series. I've been trying to wade through the commits, but it's a pretty tough slog. Does anyone have details on how to migrate plugins from <=4.3 to 4.4? Thanks, Pete Hello Peter, in 4.4 we split the plugins to the server and client plugins. Simple plugins (like server plugin) needs to exist only on server and all what is needed is to move it from ipalib/plugins to ipaserver/plugins. But if commands in your plugin define interactive_prompt_callback (like dns plugin) or forward (like vault plugin) you will need to split the client and server part of the plugin. -- David Kupka -- 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] 32 bit netmask detection and error during install
On 16/01/17 03:15, Jeff Clay wrote: I’m trying to install FreeIPA on CentOS 7. The server I’m using is a Google Cloud Compute Engine instance. For some reason, they assign all instances a /32 bit netmask on the internal interface even though you have your own private /20 subnet. When installing freeipa on these vm's, you get the error "Error: Invalid IP Address 10.128.0.5: cannot use IP network address 10.128.0.5” Here are the settings for the interface. eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1460 inet 10.128.0.5 netmask 255.255.255.255 broadcast 10.128.0.5 ether 42:01:0a:80:00:05 txqueuelen 1000 (Ethernet) RX packets 17904 bytes 116212393 (110.8 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 19001 bytes 3287390 (3.1 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 How can I bypass that error and should /32 mask detection really be there? Thanks, Hello Jeff, this issue was already fixed upstream [1]. The fix is part of 4.4.2 release. I'm afraid it's not available in CentOS yet. The easiest way would be to wait for the release to get to the CentOS or use Fedora instead. [1] https://fedorahosted.org/freeipa/ticket/5814 -- David Kupka -- 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] How to disable First time password change on IPA user
On 13/12/16 13:44, Ben .T.George wrote: HI How to disable first time password change on newly created user from web UI Regards, Ben Hi Ben, AFAIK this is not possible to do using the API. One hacky way I can think of is modifying the krbPasswordExpiration attribute in the 389ds after creation of the user. $ sudo ldapmodify -D "cn=Directory Manager" -w Secret123 -h $HOSTNAME << END_LDIF dn: uid=tuser,cn=users,cn=accounts,dc=example,dc=com changetype: modify replace: krbPasswordExpiration krbPasswordExpiration: $(date -u -d "@$(($(date +'%s')+(90*24*3600)))" +'%Y%m%d%H%M%S'Z) END_LDIF It works but I would not recommend using it in production environment. -- David Kupka -- 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] Failed ipa-client-install with IPA Replica
p admin -w Secret123 --domain example.test --server master.example.test -U [replica] # ipa-replica-install [client] # ipa-client-install -p admin -w Secret123 --domain example.test --server replica.example.test -U [client] # id admin Is there anything you've done differently? -- David Kupka -- 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] Kerberos realm for different domain
On 13/12/16 07:52, Stephen Ingram wrote:
On Sun, Dec 11, 2016 at 11:31 PM, David Kupka <dku...@redhat.com> wrote:
yes you can do it. DNS domain and Kerberos realm are two different things.
It's common and AFAIK recommended to capitalize DNS domain to get the realm
but it's not required.
If you really want to have them different make sure:
a) anotherdomain.com is under your control,
b) you don't already have other Kerberos instance (FreeIPA, MIT KRB5, MS
AD, ...) with ANOTHERDOMAIN.COM <http://anotherdomain.com/> realm
deployed.
With FreeIPA you can run
# ipa-server-install --domain example.com --realm ANOTHERDOMAIN.COM
<http://anotherdomain.com/>
But before you do, why do you want to have the realm different from the
domain?
David-
We have multiple domains that we want to manage under one Kerberos realm. I
see that's it's possible for FreeIPA to manage multiple realms, but, for
simplicity, I'd rather use just one and have all domains underneath:
REALM.COM
controls example1.com, example2.com, example3.com, etc.
Since we control all domain's DNS, we would create text records for each of
the example{x}.com domains pointing to REALM.COM Kerberos realm. We would
also create SRV records for each of the example{x}.com domains directing
Kerberos lookups to REALM.COM. I know it's a little unorthodox, but I'd
like to do it so we can keep everything in one easily managed lot.
Steve
P.S. I got several pornny spammy replies to this message. Is someone
sneaking into this list somehow?
Hello Steve,
in fact it's not possible to manage multiple Kerberos realms in one
FreeIPA deployment. And judging from your description it also isn't what
you want.
On the other hand, having one realm and multiple DNS domains is standard
situation and usually the name of the realm is derived from the primary
domain (e.g. the one that matches organization name). If all your
domains are equal just pick the one that you're most sure you'll keep
under your control.
Regarding the spamming problem, we're all receiving it and the main
problem is that the spam is not targeting freeipa-users@ list but the
individual addresses in conversations. There's not much we can do but
Simo is trying to find a solution.
--
David Kupka
--
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] Kerberos realm for different domain
On 09/12/16 22:56, Stephen Ingram wrote: Can you have a domain that belongs to a Kerberos realm with a completely different domain? For example, could example.com belong to the ANOTHERDOMAIN.COM realm as long as we control DNS for both and have all the necessary SRV and TXT records to locate it and krb5.conf is configured properly? Steve Hello Steve, yes you can do it. DNS domain and Kerberos realm are two different things. It's common and AFAIK recommended to capitalize DNS domain to get the realm but it's not required. If you really want to have them different make sure: a) anotherdomain.com is under your control, b) you don't already have other Kerberos instance (FreeIPA, MIT KRB5, MS AD, ...) with ANOTHERDOMAIN.COM realm deployed. With FreeIPA you can run # ipa-server-install --domain example.com --realm ANOTHERDOMAIN.COM But before you do, why do you want to have the realm different from the domain? -- David Kupka -- 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] nfsv4+kerberos: group ID not mapped on newly create users, however user id is correct
[1607]: No key table entry found for nfsclient$@DOMAINE.COM<mailto:nfsclient$@DOMAINE.COM> while getting keytab entry for 'nfsclient$@DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfsclient$@DOMAINE.COM<mailto:nfsclient$@DOMAINE.COM> while getting keytab entry for 'nfsclient$@DOMAINE.COM' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for root/nfsclient.domaine@domaine.com<mailto:root/nfsclient.domaine@domaine.com> while getting keytab entry for 'root/nfsclient.domaine@domaine.com' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: No key table entry found for nfs/nfsclient.domaine@domaine.com<mailto:nfs/nfsclient.domaine@domaine.com> while getting keytab entry for 'nfs/nfsclient.domaine@domaine.com' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: Success getting keytab entry for 'host/nfsclient.domaine@domaine.com' Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: INFO: Credentials in CC 'FILE:/tmp/krb5cc_machine_DOMAINE.COM' are good until 1481109339 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using FILE:/tmp/krb5cc_machine_DOMAINE.COM as credentials cache for machine creds Dec 6 12:17:16 nfsclient rpc.gssd[1607]: using environment variable to select krb5 ccache FILE:/tmp/krb5cc_machine_DOMAINE.COM Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context using fsuid 0 (save_uid 0) Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating tcp client for server jnsa-dnt2.domaine.com Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: port already set to 2049 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: creating context with server n...@jnsa-dnt2.domaine.com<mailto:n...@jnsa-dnt2.domaine.com> Dec 6 12:17:16 nfsclient rpc.gssd[1607]: DEBUG: serialize_krb5_ctx: lucid version! Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: protocol 1 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: prepare_krb5_rfc4121_buffer: serializing key with enctype 18 and size 32 Dec 6 12:17:16 nfsclient rpc.gssd[1607]: doing downcall lifetime_rec 86303 Regards Bjarne Blichfeldt. Hello, I'm almost sure that 'krbcanonicalname' has nothing to do with this. Adding krbcanonicalname attribute was done to allow principal aliases (multiple kerberos principals for one user/host/service), see [1] for details. Unfortunately, I don't know what's wrong. SSSD is taking care of resolving users and groups on enrolled systems. "id mgm" should output something like "id=1414(mgm) gid=1414(mgm) groups=1414(mgm)" if it works properly. [1] http://www.freeipa.org/page/V4/Kerberos_principal_aliases -- David Kupka -- 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] OTP Algorithm
On 30/11/16 10:13, David Kupka wrote: On 29/11/16 12:57, Callum Guy wrote: Hi Alexander, I can confirm that I am using version 4.2.0. The bug link provided mentions that it caused GA to fail to scan the codes. In my situation it is FreeIPA (or related service) which appears to fail to validate codes generated, meaning that only OTP codes generated using sha1 are validated and accepted. Just for clarity I can confirm that I have only tested OTP codes generated and configured via the FreeIPA web interface. I will check the command line generation and let you know if this makes a difference. Best Regards, Callum Hello Callum, I've tried it with FreeIPA 4.3.2 (stock Fedora 24) and FreeOTP. I've generated 3 OTPs (with sha256, sha384 and sha512) for tuser in the WebUI and was then able to login into WebUI without problems. $ ipa otptoken-find --owner tuser --all 3 OTP tokens matched dn: ipatokenuniqueid=3c899764-7abf-459d-bf2b-7ba4af978a8b,cn=otp,dc=dom-058-216,dc=example,dc=com Unique ID: 3c899764-7abf-459d-bf2b-7ba4af978a8b Type: TOTP Owner: tuser Key: U5XDN0BYc9KbvG1iYuVPuVHB448= Algorithm: sha256 Digits: 6 Clock offset: 0 Clock interval: 30 ipatokentotpwatermark: 49349880 objectclass: top, ipatokentotp, ipatoken dn: ipatokenuniqueid=40ad189b-7b7c-44b9-8450-b3eb78057ef6,cn=otp,dc=dom-058-216,dc=example,dc=com Unique ID: 40ad189b-7b7c-44b9-8450-b3eb78057ef6 Type: TOTP Owner: tuser Key: C79y2W+I0z429eRzsRP7qdpROaI= Algorithm: sha512 Digits: 6 Clock offset: 0 Clock interval: 30 ipatokentotpwatermark: 49349882 objectclass: top, ipatokentotp, ipatoken dn: ipatokenuniqueid=baf6d329-61ad-46f1-beca-6ddb55ba9bb4,cn=otp,dc=dom-058-216,dc=example,dc=com Unique ID: baf6d329-61ad-46f1-beca-6ddb55ba9bb4 Type: TOTP Owner: tuser Key: 2hxrsJjQ6e+3qzVPZremtsB/NCg= Algorithm: sha384 Digits: 6 Clock offset: 0 Clock interval: 30 ipatokentotpwatermark: 49349881 objectclass: top, ipatokentotp, ipatoken I've tried with Google Authenicator too and was unable to login. Alexander found issue [1] asking for SHA256 support. From comment on the issue it appear that SHA1 is the only supported hash. I compared codes generated by oathtool [2] and find out that Google Authenticator just ignores the information about used hash function and uses SHA1 without any error or warning. So I can only recommend switching to FreeOTP or returning to SHA-1 hash function. [1] https://github.com/google/google-authenticator-libpam/issues/11 [2] http://www.nongnu.org/oath-toolkit/oathtool.1.html On Tue, Nov 29, 2016 at 11:51 AM Alexander Bokovoy <aboko...@redhat.com> wrote: On ti, 29 marras 2016, Callum Guy wrote: Hi Petr, Thanks for coming back to me on this. I have only tried using Google Authenticator. The generated QR code successfully scans and codes are then generated on the GA device as normal. The problem is that the codes simply do not work. My current thinking is that the service which interprets the codes server-side is not configured to use the same algorithm meaning that it is trying to validate sha256/sha512 (both tested and not functional for me) etc codes against codes perhaps generated with sha1 (the only algorithm that appears to work). I apologise in advance for my naive interpretation of the situation, this really isn't an area where i have experience. I'd love to understand whats going on however I can't find what i need in the OTP documentation. Which IPA version we are talking about? There was a case when the URI generated by 'ipa otptoken-add' was using a wrong case in the algorithm value and this was breaking Google Authenticator. https://fedorahosted.org/freeipa/ticket/5047 This bug was fixed since 4.1.5 release. Best Regards, Callum On Tue, Nov 29, 2016 at 11:10 AM Petr Vobornik <pvobo...@redhat.com> wrote: On 11/28/2016 01:03 PM, Callum Guy wrote: Hi All, I wanted to ask a quick question - perhaps a more experienced user will be able to help or point me to the correct documentation. Basically we have implemented password+OTP type authentication which works great. When adding a OTP code using the admin login you can choose an algorithm. For us the generated codes only work properly if the weakest sha1 algorithm is chosen/ To be clear the code generation works fine but the codes are not valid when logging in. Is there a related setting we must change? Thanks, Callum What type of otp token do you use? Does it work with some different? E.g. FreeOTP vs Google Authenticator ... -- Petr Vobornik -- *0333 332 | www.x-on.co.uk <http://www.x-on.co.uk> | ** <https://twitter.com/xonuk> <http://www.linkedin.com/company/x-on/products> <https://www.facebook.com/XonTel> * X-on is a trading name of Storacall Technology Ltd a limited company registered in England and Wales. Registered Office : Avaland H
Re: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process
On 29/11/16 13:55, David Dejaeghere wrote: Correct. Same symptoms. 2016-11-29T10:29:42Z DEBUG certmonger request is in state dbus.String(u'CA_UNREACHABLE', variant_level=1) Fedora 24 Server [root@ns02 ~]# dnf history userinstalled Packages installed by user freeipa-client-4.3.2-2.fc24.x86_64 freeipa-server-4.3.2-2.fc24.x86_64 grub2-1:2.02-0.34.fc24.x86_64 kernel-4.5.5-300.fc24.x86_64 kernel-4.8.8-200.fc24.x86_64 lvm2-2.02.150-2.fc24.x86_64 xfsprogs-4.5.0-2.fc24.x86_64 Ok. I've reproduced it by simply stopping dogtag on FreeIPA server while installing the replica. I see the exactly same errors as you've reported and are described in the ticket, now. Is dogtag running on your master? Is in responding (e.g. issuing certificates for users)? Is it accessible from the replica? 2016-11-29 13:41 GMT+01:00 Petr Vobornik <pvobo...@redhat.com>: On 11/29/2016 12:43 PM, David Kupka wrote: On 29/11/16 12:15, David Dejaeghere wrote: Seems like it is but it does not show a server cert for dirsrv [root@ns02 ~]# ls -lZ /etc/dirsrv/slapd-SOMETHING-BE/ total 468 -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 65536 Nov 29 11:29 cert8.db -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 65536 Nov 29 11:29 cert8.db.orig -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 1623 Nov 29 11:29 certmap.conf -rw---. 1 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif.bak -rw---. 2 dirsrv dirsrv system_u:object_r:dirsrv_config_t:s0 89977 Nov 29 11:29 dse.ldif.startOK -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 36228 Nov 29 11:28 dse_original.ldif -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 key3.db -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 key3.db.orig -r. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s066 Nov 29 11:29 pin.txt -rw---. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s040 Nov 29 11:29 pwdfile.txt drwxrwx---. 2 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 4096 Nov 29 11:29 schema -rw---. 1 dirsrv root unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 secmod.db -rw-rw. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 16384 Nov 29 11:29 secmod.db.orig -r--r-. 1 dirsrv dirsrv unconfined_u:object_r:dirsrv_config_t:s0 15142 Nov 29 11:28 slapd-collations.conf [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=something-PAPRIKA-CA,DC=something,DC=local CT,C,C SOMETHING.BE IPA CA CT,C,C [root@ns02 ~]# certutil -d /etc/dirsrv/slapd-SOMETHING-BE -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI CN=something-PAPRIKA-CA,DC=something,DC=local CT,C,C SOMETHING.BE IPA CA CT,C,C [root@ns02 ~]# ausearch -m avc -i Exactly, the NSSDB should be accessible to dirsrv and is missing the Server-Cert but I don't understand why there's "bad database" error in the errors log. I'll try to reproduce it. What version of FreeIPA are you using? On what system? Right. Seems bit similar to https://fedorahosted.org/freeipa/ticket/6514 would be good to check if it has the same symptoms, mainly certmonger request is in state dbus.String(u'CA_UNREACHABLE', variant_level=1) in replica install log. 2016-11-29 12:09 GMT+01:00 David Kupka <dku...@redhat.com>: On 29/11/16 11:51, David Dejaeghere wrote: Hi, I have a setup where i want to add a replica. The first master setup has an externally signed cert for dirsrv and httpd. The replica is prepapred succesfully with ipa-client-install but the replica install then keeps failing. It seems that during install dirserv is not configured correctly with a valid server certificate. Output from the dirsrv error added to this email as well. [root@ns02 ~]# ipa-replica-install --setup-ca WARNING: conflicting time synchronization service 'chronyd' will be disabled in favor of ntpd Run connection check to master Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv). Estimated time: 1 minute [1/43]: creating directory server user [2/43]: creating directory server instance [3/43]: restarting directory server [4/43]: adding default schema [5/43]: enabling memberof plugin [6/43]: enabling winsync plugin [7/43]: configuring replication version plugin [8/43]: enabling IPA enrollment plugin [9/43]: enabling ldapi [10/43]: configuring uniq
Re: [Freeipa-users] ipa-replica-install failing, dirsrv not starting properly during install process
On 29/11/16 11:51, David Dejaeghere wrote: Hi, I have a setup where i want to add a replica. The first master setup has an externally signed cert for dirsrv and httpd. The replica is prepapred succesfully with ipa-client-install but the replica install then keeps failing. It seems that during install dirserv is not configured correctly with a valid server certificate. Output from the dirsrv error added to this email as well. [root@ns02 ~]# ipa-replica-install --setup-ca WARNING: conflicting time synchronization service 'chronyd' will be disabled in favor of ntpd Run connection check to master Connection check OK Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv). Estimated time: 1 minute [1/43]: creating directory server user [2/43]: creating directory server instance [3/43]: restarting directory server [4/43]: adding default schema [5/43]: enabling memberof plugin [6/43]: enabling winsync plugin [7/43]: configuring replication version plugin [8/43]: enabling IPA enrollment plugin [9/43]: enabling ldapi [10/43]: configuring uniqueness plugin [11/43]: configuring uuid plugin [12/43]: configuring modrdn plugin [13/43]: configuring DNS plugin [14/43]: enabling entryUSN plugin [15/43]: configuring lockout plugin [16/43]: configuring topology plugin [17/43]: creating indices [18/43]: enabling referential integrity plugin [19/43]: configuring certmap.conf [20/43]: configure autobind for root [21/43]: configure new location for managed entries [22/43]: configure dirsrv ccache [23/43]: enabling SASL mapping fallback [24/43]: restarting directory server [25/43]: creating DS keytab [26/43]: retrieving DS Certificate [27/43]: restarting directory server ipa : CRITICAL Failed to restart the directory server (Command '/bin/systemctl restart dirsrv@SOMETHING-BE.service' returned non-zero exit status 1). See the installation log for details. [28/43]: setting up initial replication [error] error: [Errno 111] Connection refused Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. [29/Nov/2016:11:29:44.034285579 +0100] SSL alert: Security Initialization: Can't find certificate (Server-Cert) for family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) [29/Nov/2016:11:29:44.045039728 +0100] SSL alert: Security Initialization: Unable to retrieve private key for cert Server-Cert of family cn=RSA,cn=encryption,cn=config (Netscape Portable Runtime error -8174 - security library: bad database.) Hello David, The error from the log indicates that either the NSSDB for dirsrv is not initialized or not accessible. Could you please send output of the following commands? # ls -lZ /etc/dirsrv/slapd-$REALM/ # certutil -d /etc/dirsrv/slapd-$REALM/ -L # ausearch -m avc -i -- David Kupka -- 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] bind-dyndb-ldap and replication requirements
On 10/11/16 01:14, Brendan Kearney wrote:
i am asking this for a friend who is trying to figure out how to get
bind-dyndb-ldap working against openldap on ubuntu. she does not have
replication between two or more ldap instances, and needs to figure out
the minimum requirements for bind-dyndb-ldap. i have been trying to
help her, but i am unsure about what is needed, as i have n-way multi
master replication working already.
can anyone provide what the replication requirements are for
bind-dyndb-ldap? currently, the SyncRepl module is loaded and the
overlay is created and configured for the mdb. i have tried to help get
olcServerID and olcMirrorMode set in cn=config and
olcDatabase={2}mdb,cn=config respectively, but some errors were
encountered there. is there a best practices doc that we can review?
the environment, as best i can tell is ubuntu, openldap 2.4.42 and bind
9. exact os and bind versions are not known right now.
thanks,
brendan kearney
Hello Brendan,
I don't have any experience with running OpenLDAP + bind-dyndb-ldap but
quick web search showed me this:
https://blogs.mindspew-age.com/2013/06/07/bind-dns-openldap-mdb-dynamic-domainsub-domain-configuration-of-dns/
The article is about CentOS 6 and more than 3 years old but still might
be helpful because it's mainly about Bind 9 configuration.
--
David Kupka
--
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] Do expired passwords remain usable indefinitely?
On 25/10/16 01:02, Prasun Gera wrote:
I've seen some different behaviour. I've had errors for users (including
the admin user) trying to log in with possibly an expired password. Both
webui and ssh would fail, but kinit would work. I'm not sure if this is
related to the password's expiration or the account's expiration. My
/var/log/secure has messages like "pam_sss(sshd:auth): received for user
uname: 13 (User account has expired)". Is there a setting for default
expiration of user accounts ? I don't remember setting it anywhere.
On Mon, Oct 24, 2016 at 8:13 AM, David Kupka <dku...@redhat.com> wrote:
On 21/10/16 15:17, Brian Candler wrote:
Question: when a password expires, does it remain in a usable state in
the database indefinitely? For example, if someone comes along a year
after their password has expired, can they still login once with that
password?
This is actually what I want, but I just want to confirm there's not
some sort of secondary threshold which means that an expired password is
not usable X days after it has expired. Or, if there is such a
secondary threshold, where I can find it.
The scenario is a RADIUS server for wifi which reads NTLM password
hashes out of the database to authenticate - this continues to work
after expiry. However I want users to be able to do a self-reset later
if and when they want to.
Thanks,
Brian.
Hello Brian!
AFAIK, it will work. Your RADIUS server will retrieve the hash from LDAP
and do the validation locally. So FreeIPA has no way to say the password is
expired.
When the user tries to obtain Kerberos ticket he will be forced to change
the password and NTLM hash will be also regenerated.
--
David Kupka
--
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
Hello Prasun!
If I understood Brian correctly he was asking about expiration of NTLM
password hashes. In his case there is no checking for password or
account expiration. It would need to be done in RADIUS server itself
because RADIUS server just fetches the attributes from LDAP and does
whatever it is programmed to do.
The situation that you're describing looks weird to me. When user's
Kerberos Password expires kinit and WebUI forces password change on next
login attempt. I don't know how ssh client behaves.
When user's Kerberos Principal ("account") expires neither WebUI nor
kinit would allow login or password change. Administrator must prolong
or remove the Kerberos Principal expiration.
By default Kerberos Password expiration is set according relevant to
password policy (global_policy by default) and Kerberos Principal
expiration is not set.
--
David Kupka
--
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] Certmonger (or similar) for FreeBSD?
On 24/10/16 19:26, Gilbert Wilson wrote: On Oct 24, 2016, at 5:51 AM, David Kupka <dku...@redhat.com> wrote: On 22/10/16 00:15, Gilbert Wilson wrote: We have a lot of FreeBSD systems that I would like to streamline certificate issuance and renewal. Ideally, we could leverage our FreeIPA system's CA to do this. But, certmonger doesn't run on FreeBSD (or does it?). What other means have other people tried, or would you recommend investigating, to enable automated certificate issuance and renewal for FreeBSD FreeIPA clients? Any pointers are appreciated! Gil Hello Gil! I've very limited experiences with *BSD systems so the question may be completely off. Have you tried to install and run certmonger using FreeBSD's Linux Binary Compatibility [1]? Though I don't know what are the limitations or possible issues it could be a way. [1] http://www.freebsd.cz/doc/handbook/linuxemu.html -- David Kupka You know… I haven’t ever tried LBC! I suppose it’s worth a sacrificial virtual machine to see if it works. It also occurred to me that FreeIPA might have some sort of API given the web interface, and sure enough that made the Google-fu turn up more useful results. * https://vda.li/en/posts/2015/05/28/talking-to-freeipa-api-with-sessions/ * https://adam.younglogic.com/2010/07/talking-to-freeipa-json-web-api-via-curl/ * http://www.admin-magazine.com/Archive/2016/34/A-REST-interface-for-FreeIPA There doesn’t appear to be a manual for the API but those examples seem to “show the way”. My initial thought is to create a script that uses kinit with a keytab to authenticate against FreeIPA and then create/renew permissible certificates for the system before they expire. This seems reasonable since the certificate creation/renewal is the scope of what I’m interested in doing. Do you see any reason not to do it this way or have any other alternative suggestions? Another way to think about it, perhaps, is what would you do on a Linux system if you didn’t have access to the FreeIPA client or certmonger? Thanks for the pointer/reminder about LBC! Gil You're right, FreeIPA has JSON RPC API. It's used in WebUI and also in 'ipa' CLI. If you've FreeIPA server 4.2 and above there's API Browser in WebUI (IPA Server - API Browser). There you can find all commands and their parameters. Just obligatory disclaimer, talking directly to the API is not officially supported. This means that the API can change in future versions. Good luck! -- David Kupka -- 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] Certmonger (or similar) for FreeBSD?
On 22/10/16 00:15, Gilbert Wilson wrote: We have a lot of FreeBSD systems that I would like to streamline certificate issuance and renewal. Ideally, we could leverage our FreeIPA system's CA to do this. But, certmonger doesn't run on FreeBSD (or does it?). What other means have other people tried, or would you recommend investigating, to enable automated certificate issuance and renewal for FreeBSD FreeIPA clients? Any pointers are appreciated! Gil Hello Gil! I've very limited experiences with *BSD systems so the question may be completely off. Have you tried to install and run certmonger using FreeBSD's Linux Binary Compatibility [1]? Though I don't know what are the limitations or possible issues it could be a way. [1] http://www.freebsd.cz/doc/handbook/linuxemu.html -- David Kupka -- 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] Do expired passwords remain usable indefinitely?
On 21/10/16 15:17, Brian Candler wrote: Question: when a password expires, does it remain in a usable state in the database indefinitely? For example, if someone comes along a year after their password has expired, can they still login once with that password? This is actually what I want, but I just want to confirm there's not some sort of secondary threshold which means that an expired password is not usable X days after it has expired. Or, if there is such a secondary threshold, where I can find it. The scenario is a RADIUS server for wifi which reads NTLM password hashes out of the database to authenticate - this continues to work after expiry. However I want users to be able to do a self-reset later if and when they want to. Thanks, Brian. Hello Brian! AFAIK, it will work. Your RADIUS server will retrieve the hash from LDAP and do the validation locally. So FreeIPA has no way to say the password is expired. When the user tries to obtain Kerberos ticket he will be forced to change the password and NTLM hash will be also regenerated. -- David Kupka -- 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] help
On 17/10/16 02:44, 郑磊 wrote: Hello everyone, I'm using freeipa, and having a test and research with the function of freeipa. At the same time, I have carried on the chinese translation to the web interface, also added own function module in web interface. However, For these changes I don't know how to interact with the community, please help me. Thank you very much! Hello! Do you have problem with developing your own module? Ask on freeipa-de...@redhat.com Is your module complete, you think that it will be useful for a lot of FreeIPA users and want it in upstream? Create pull request on GitHub (https://github.com/freeipa/freeipa ). Do you want to contribute the translations? Submit it via zanata (https://fedora.zanata.org/project/view/freeipa ). HTH, -- David Kupka -- 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] How to make a FreeIPA node replica become Master?
On 14/09/16 23:19, Sergio Francisco wrote: Hi, We have a deployment of FreeIPA using 3 nodes (Master with more 2 replicas). Recently, the master node had a problem with the process 'ns-slapd' consuming 100% of CPU. During this problem, DNS service wasn't working, IPA admin UI encountered timeout, SSH keys to access the hosts are not being loaded correctly. We observed in the logs of "dirsrv" that something related to the cachesize wasn't enough to the space needed and then ns-slapd started a process to recover it. We let the server running this operation almost one day and nothing happened. Today, we tried to: 1 - remove the failed server from the deployment, using the command below, but unfortunately, it wasn't possible to do from both the 2 other nodes. ipa-replica-manage del --force mux-idm-p03.muxi.dc --cacert=/etc/ipa/ca.crt unexpected error: cannot connect to 'ldaps://localhost.localdomain:636 2 - tried to upgrade the failed server to a most recent version of IPA using ipa-server-upgrade but it stopped in the step to connect [5/10]: starting directory server 2016-09-14T13:43:28Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2016-09-14T13:43:28Z DEBUG The ipa-server-upgrade command failed, exception: error: [Errno 111] Connection refused 2016-09-14T13:43:28Z ERROR [Errno 111] Connection refused 3 - tried to recover the 389-ds database with the command "db_recover -f -v" but nothing happened. 4 - visited similar threads but none of them helped me https://www.redhat.com/archives/freeipa-users/2013-May/msg00015.html https://www.redhat.com/archives/freeipa-users/2015-July/msg00188.html 5 - as we need to urgently recover the service, we tried to rebuild the failed server, removing and reinstalling all the packages needed by ipa-server (yum install ipa-server bind bind-dyndb-ldap ipa-server-dns) and tried to re-join the new server as a replica to receive all the data again, but it doesn't seems to work. The other nodes are working well, resolving DNS requests, allowing users to access the servers using SSH, etc. Any ideas of what I can do to rebuild the server? Versions ipa-server-4.2.0-15.0.1.el7.centos.19.x86_64 ipa-server-dns-4.2.0-15.0.1.el7.centos.19.x86_64 389-ds-base-1.3.4.0-33.el7_2.x86_64 CentOS Linux release 7.2.1511 (Core) Hi Sergio, first of all the terms master and replica are misleading. All FreeIPA servers are masters because the backends (389-ds) are configured to maintain multi-master replication. The difference between masters may be in services (CA, DNS, KRA, AD Trust, ...) that was configured on particular master but the data are synchronized among all masters. Looking on the steps you've done it would be best to create new master as a replica of one of the existing masters. Then you will probably need to enable CRL generating on some master because this can be enable only on one master and by default is enabled on first master that is installed with CA. Here you can find more information and how to: https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master HTH, -- David Kupka -- 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] (no subject)
On 24/08/16 19:08, Sean Hogan wrote: Hi All, Would anyone be able to direct me to some docs regarding NFS automount with IPA. We are currently using this setup but to be specific I do not want the priv keys to be in the users mounted home. When I did the keygen I took the defaults for location and it went into the exported home of the user meaning it is mounted on any system the user logs onto which is not a good idea. Is there a way to set this up so the priv keys stay out of the mounted home or since I have the keys uploaded into IPA I do not need the key in home? Sean Hogan Hello Sean, You can find the documentation here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#automount But I don't understand what is wrong with the setup. AFAIU NFS, shares must be mounted only on machines where you (admin) have full control and therefore ownership and access permissions can be enforced. Then ~/.ssh directory must have mode 0700 and all files inside it 0600. If you obey these rules storing ssh keys on NFS share is no less secure than storing them locally. -- David Kupka -- 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] Moving from ca to ca-less without pki
On 29/07/16 15:35, Andreas Ladanyi wrote: Hi, is it simply possible to move from ca to a ca-less environment in ipa ? Because its ok for me to only use certificates in web and ldap components. I use freeipa 4.2 , fedora 23. regards, Andreas Hello Andreas! There is no tool that would do this for you, yet. You can manually remove CS entries from LDAP, remove CS instance, stop tracking certificates in certmonger and replace certificates for apache and dirsrv. But be very cautious any mistake may destroy the whole freeipa server and all data stored there. ipa-cacert-manage does the opposite (installing CS on CA-less freeipa server). Feel free to file an RFE https://fedorahosted.org/freeipa/newticket -- David Kupka -- 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] How to unset a user's kerberos principal expiration date?
On 29/06/16 19:05, Roderick Johnstone wrote: Hi If I set a kerberos principal for a user to expire on a given date using: ipa user-mod --principal-expiration=DATE is it possible to later remove this expiration date rather than just set it to a time far in the future? Thanks Roderick Johnstone Hello Roderick, AFAIK the only way to remove principal expiration at the time is remove krbPrincipalExpiration attribute from the user entry in DS. $ kinit admin Password for ad...@example.org $ ldapmodify -Y GSSAPI SASL/GSSAPI authentication started SASL username: ad...@example.org SASL SSF: 56 SASL data security layer installed. dn:uid=tuser,cn=users,cn=accounts,dc=example,dc=org changetype: modify delete: krbprincipalexpiration modifying entry "uid=tuser,cn=users,cn=accounts,dc=example,dc=org" I think that it makes sense to expose this in API. Could you please file RFE (https://fedorahosted.org/freeipa/newticket)? -- David Kupka -- 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] SSH login to client
On 09/06/16 13:18, Pavel Picka wrote: Hi, Have anyone experience, when create user on ipa-server, and want to login on client with this user I get : Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). (with kinit [1st time change] was password changed to new one) even with another change with ipa user-mod --password I am getting same result and on client in /var/log/messages found : Jun 9 12:36:02 rhel04 [sssd[krb5_child[4635]]]: Decrypt integrity check failed Jun 9 12:36:02 rhel04 [sssd[krb5_child[4635]]]: Decrypt integrity check failed Jun 9 12:36:05 rhel04 [sssd[krb5_child[4637]]]: Decrypt integrity check failed Jun 9 12:36:05 rhel04 [sssd[krb5_child[4637]]]: Decrypt integrity check failed Jun 9 12:36:28 rhel04 [sssd[krb5_child[4641]]]: Decrypt integrity check failed Jun 9 12:36:28 rhel04 [sssd[krb5_child[4641]]]: Decrypt integrity check failed -- Pavel Picka Hi Pavel! I have few questions that may help locating the issue: Are you able to kinit as the user on server and client? Are you able to ssh to the client as the admin? What is the output of "id user" on client? -- David Kupka -- 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] mod_nss FreeIPA
On 26/05/16 07:42, Günther J. Niederwimmer wrote: Hello, can any help to find the correct way to configure a Webserver with IPA. (mod_nss) I can't create a correct DB in /etc/httpd/alias I search on the INet and read the install Log from ipa-server but it is for me not possible to found a working way :-(. Thanks for a answer ? Hello Günther, I'm not sure if I understand your question. What I take from you message is: I want a IPA webserver with NSSDB in /etc/httpd/alias. The answer then is: ipa-server-install creates that DB for apache and populates it with certificates. So there is nothing to do. From one of my test servers: # certutil -d /etc/httpd/alias/ -L Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI ipaCert u,u,u Server-Cert u,u,u EXAMPLE.TEST IPA CA CT,C,C Signing-Cert u,u,u If this is not what you was asking please try to explain what you want to achieve with more details. -- David Kupka -- 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] ca-error: Error setting up ccache for local "host" service using default keytab: Clock skew too great.
-01-29 14:09:45 UTC eku: id-kp-serverAuth pre-save command: post-save command: track: yes auto-renew: yes Request ID '20130519130741': status: NEED_CSR_GEN_PIN ca-error: Internal error: no response to "http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=61=true=true;. stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin='297100916664 ' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=sample.NET subject: CN=CA Audit,O=sample.NET expires: 2017-10-13 14:10:49 UTC pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130519130742': status: NEED_CSR_GEN_PIN ca-error: Internal error: no response to "http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=60=true=true;. stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin='297100916664 ' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=sample.NET subject: CN=OCSP Subsystem,O=sample.NET expires: 2017-10-13 14:09:49 UTC eku: id-kp-OCSPSigning pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130519130743': status: NEED_CSR_GEN_PIN ca-error: Internal error: no response to "http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=62=true=true;. stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='297100916664 ' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=sample.NET subject: CN=CA Subsystem,O=sample.NET expires: 2017-10-13 14:09:49 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/lib64/ipa/certmonger/stop_pkicad post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20130519130744': status: MONITORING ca-error: Internal error: no response to "http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=64=true=true;. stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='ipaCert',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=sample.NET subject: CN=RA Subsystem,O=sample.NET expires: 2017-10-13 14:09:49 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/lib64/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20130519130745': status: NEED_CSR_GEN_PIN ca-error: Internal error: no response to "http://test.sample.net:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=63=true=true;. stuck: yes key pair storage: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB',pin='297100916664 ' certificate: type=NSSDB,location='/var/lib/pki-ca/alias',nickname='Server-Cert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-renew-agent issuer: CN=Certificate Authority,O=sample.NET subject: CN=test.sample.net <http://test.sample.net>,O=sample.NET expires: 2017-10-13 14:09:49 UTC eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes -- Thanks, Anthony Hello Anthony! After stopping NTP (or other time synchronizing service) and setting time manually server really don't have a way to determine that its time differs from the real one. I think this might be issue with Kerberos ticket. You can show content of
Re: [Freeipa-users] can live turn off nsslapd-security: to off ?
On 27/04/16 13:15, barry...@gmail.com wrote: Do u meant use ldapmodify? I tried update the dse.ldif but it will fall back after a while. 2016年4月27日 下午7:10 於 "David Kupka" <dku...@redhat.com <mailto:dku...@redhat.com>> 寫道： On 27/04/16 12:48, barry...@gmail.com <mailto:barry...@gmail.com> wrote: Hi: Without restarting dirsrv possible do that ? thx Regards barry Hello Barry, this ldapsearch should list all attributes that needs restart after modification: $ ldapsearch -D "cn=Directory Manager" -w Secret123 -b cn=config nsslapd-requiresrestart I don't see nsslapd-security listed so it should be possible to change it in runtime. -- David Kupka Yes, I mean ldapmodify. Editing dse.ldif while dirsrv is running has no effect because it is read only at start and written at least before exit. If you REALLY need to edit dse.ldif be sure to stop dirsrv then edit it and start dirsrv again. -- David Kupka -- 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 live turn off nsslapd-security: to off ?
On 27/04/16 12:48, barry...@gmail.com wrote: Hi: Without restarting dirsrv possible do that ? thx Regards barry Hello Barry, this ldapsearch should list all attributes that needs restart after modification: $ ldapsearch -D "cn=Directory Manager" -w Secret123 -b cn=config nsslapd-requiresrestart I don't see nsslapd-security listed so it should be possible to change it in runtime. -- David Kupka -- 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] Best practice for requesting a certificate in Kickstart?
On 24/04/16 04:46, Anthony Clark wrote: Hello All, TL;DR: what's the best way to grab a SSL cert and key during kickstart? (this is all using CentOS 7.2 latest) I'm using Foreman to manage my kickstart and Puppet services, and its built-in FreeIPA client enrollment works just fine. However I'd like to also request a certificate and key for a Puppet client to use to authenticate to the Foreman-controlled Puppet server. If I manually set up a puppet client then it works just fine. I use something like this: # ipa-getcert request -w -r -f /var/lib/puppet/ssl/certs/<%= @host.name <http://host.name> %>.pem -k /var/lib/puppet/ssl/private_keys/<%= @host.name <http://host.name> %>.pem # cp /etc/ipa/ca.crt /var/lib/puppet/ssl/certs/ca.pem (then setting the correct paths and settings in /etc/puppet/puppet.conf) I tried to make that work inside the Kickstart process, but as those commands are running inside a kickstart chroot the certmonger service won't start. Is there a better method to grab a SSL cert and key for the host during kickstart? Or should I just wait until firstboot and perform the steps at that point? Many Thanks and FreeIPA is really amazing! Anthony Clark Hello Anthony, TL;DR Set DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null in kickstart chroot environment before calling "ipa-getcert request". The issue is already addressed by BZ1134497 [1]. When getcert detects there is no DBus it starts certmonger and communicates over unix socet. But in Kickstart environment DBus is available but unusable (BZ1271551, [2]). It can be workaround by setting DBUS_SYSTEM_BUS_ADDRESS=unix:path=/dev/null (it is described in Doc Text of [1]). You can also run ipa-client-install with --request-cert and it will also request certificate for the client. And also require the workaround in Kickstart chroot environment. But unlike "ipa-getcert request -w" it won't wait for the certificate to be issued and fetched. The reason is that it can take days for certificate to be issued (some CAs require human approval) so ipa-client-install only submit the request and doesn't wait for certificate. After the installation completes and system is started certmonger periodically query for the certificate and fetch it when available. [1] https://bugzilla.redhat.com/show_bug.cgi?id=1134497 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1271551 HTH, -- David Kupka -- 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] Object class violation
On 17/04/16 07:23, Günther J. Niederwimmer wrote:
Hello,
I like to setup / install a replica for my IPA Server.
Now I have this Error
Configuring Kerberos KDC (krb5kdc). Estimated time: 30 seconds
[1/8]: adding sasl mappings to the directory
[2/8]: configuring KDC
[3/8]: creating a keytab for the directory
[4/8]: creating a keytab for the machine
[5/8]: adding the password extension to the directory
[6/8]: enable GSSAPI for replication
[error] OBJECT_CLASS_VIOLATION: {'desc': 'Object class violation'}
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
ipa.ipapython.install.cli.install_tool(Replica): ERROR{'desc': 'Object
class violation'}
Have I also to delete the replica on the IPA Server ?
Or can I repair the replica ?
Hello,
the simplest way is to run # ipa-server-install --uninstall -U on
replica and # ipa-replica-manage del on master.
But I don't understand why did you get the "Object class violation"
error. Have you changed the schema on IPA server? Or done any other changes?
If not could you please file a ticket
(https://fedorahosted.org/freeipa/newticket) and provide reproducer?
--
David Kupka
--
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] howto ldapsearch for disabled/enabled users?
On 15/04/16 13:31, Harald Dunkel wrote: Hi folks, I have no luck with the ipa cli, so I wonder if it is possible to ldapsearch for disabled or enabled users? A command line like ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=com uid=somebody doesn't show :-(. Every helpful hint is highly welcome Harri Hello Harri, the attribute you're looking for is 'nsaccountlock'. This command should give you uids of all disabled users: $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=test "(nsaccountlock=TRUE)" uid -- David Kupka -- 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 -v ping lies about the cert database
On 15/04/16 11:42, Harald Dunkel wrote: Hi folks, If I run "kinit admin; ipa -v ping" as a regular user, then I get ipa: INFO: trying https://ipa2.example.com/ipa/json ipa: INFO: Connection to https://ipa2.example.com/ipa/json failed with (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. ipa: INFO: trying https://ipa1.example.com/ipa/json ipa: INFO: Connection to https://ipa1.example.com/ipa/json failed with (SEC_ERROR_LEGACY_DATABASE) The certificate/key database is in an old, unsupported format. ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa2.example.com/ipa/json, https://ipa1.example.com/ipa/json Using root there is no problem. Obviously this is a Unix access problem, not an old database. I would like to avoid running maintenance scripts as root, if possible. The error message doesn't include any path information, so I wonder how I can fix the access problem without opening the system too wide? Every helpful hint is highly appreciated Harri Hello Harri, the FreeIPA certificate database is stored in /etc/ipa/nssdb, by default the permissions are set to: $ ls -dl /etc/ipa/nssdb/ drwxr-xr-x. 2 root root 73 Apr 15 14:00 /etc/ipa/nssdb/ $ ls -l /etc/ipa/nssdb/ total 80 -rw-r--r--. 1 root root 65536 Apr 15 14:00 cert8.db -rw-r--r--. 1 root root 16384 Apr 15 14:00 key3.db -rw---. 1 root root40 Apr 15 14:00 pwdfile.txt -rw-r--r--. 1 root root 16384 Apr 15 14:00 secmod.db Please check the permission on your system. If it's different and you (or system admin) haven't changed it please file a ticket (https://fedorahosted.org/freeipa/newticket). -- David Kupka -- 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] freeipa restore backup on a new server
On 12/04/16 11:26, Rakesh Rajasekharan wrote: Hi , I am running ipa-server verison 4.2 on AWS,and testing the freeipa backup and restore . The restoration works fine if its on the same host, wherin i uninstall freeipa and then install it back and then do a full restore. However, if its a new machine with a different ip, the restoration fails. I am running the restoration from an ansible playbook.. heres the output, that I get Preparing restore from /tmp/ipa/ipa-full-2016-04-12 on test-ipa-master-int.xyz.com <http://test-ipa-master-int.xyz.com> Performing FULL restore from FULL backup Each master will individually need to be re-initialized or re-created from this one. The replication agreements on masters running IPA 3.1 or earlier will need to be manually re-enabled. See the man page for details. Disabling all replication. Stopping IPA services Systemwide CA database updated. Restoring files Systemwide CA database updated. Restoring from userRoot in xyz-COM Restoring from ipaca in xyz-COM Starting IPA services Command ''ipactl' 'start'' returned non-zero exit status 1 stdout: Configuring certmonger to stop tracking system certificates for CA Is there a limitation that the ip needs to be the same for a restore to happen or am I missing something. Thanks, Rakesh Hello Rakesh, it's not possible to determine what happened from information that you have sent. Could you please find the service that failed to start and send its logs? I believe that all services in FreeIPA depends on host names and resolve IP address from DNS when needed. But if DNS server is part of FreeIPA server you're trying to restore it is holding old records with old IP addresses. Maybe this is the cause but it's just wild guess. -- David Kupka -- 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] Not able to get kerberos ticket from keytab
On 26/02/16 08:56, David Kupka wrote: On 26/02/16 02:22, Teik Hooi Beh wrote: Hi, I have manged to deployed 1 ipa master and 1 ipa client with success on centos 7.2 with freeipa v4.2. I also managed to create user and set sshd-rules to for ttester user and also successfully get krb ticket using *kinit ttes...@example.my*. I am trying to deploy password-less SSH login with kerberos using the following guide ( https://uz.sns.it/~enrico/wordpress/2014/03/password-less-ssh-login-with-kerberos/) - snippet - *$ ktutil ktutil: add_entry -password -p ttes...@example.my -k 1 -e aes256-cts-hmac-sha1-96 ktutil: write_kt keytab* When I tried *kinit -kt keytab ttes...@example.my*, I get *"**kinit: Password incorrect while getting initial credentials"* Doing a trace using KRB5_TRACE on both calls *1. KRB5_TRACE=/dev/stderr kinit ttes...@example.my* 27242] 1456447025.219676: Getting initial credentials for ttes...@example.my [27242] 1456447025.222070: Sending request (164 bytes) to EXAMPLE.MY [27242] 1456447025.23: Resolving hostname node1.example.my [27242] 1456447035.238004: Initiating TCP connection to stream 192.168.38.2:88 [27242] 1456447035.238675: Sending TCP request to stream 192.168.38.2:88 [27242] 1456447035.241248: Received answer (337 bytes) from stream 192.168.38.2:88 [27242] 1456447035.241257: Terminating TCP connection to stream 192.168.38.2:88 [27242] 1456447035.241377: Response was from master KDC [27242] 1456447035.241437: Received error from KDC: -1765328359/Additional pre-authentication required [27242] 1456447035.241484: Processing preauth types: 136, 19, 2, 133 [27242] 1456447035.241499: Selected etype info: etype aes256-cts, salt "s`GD^,#=cA:Vr9hD", params "" [27242] 1456447035.241504: Received cookie: MIT Password for ttes...@example.my: [27242] 1456447062.215750: AS key obtained for encrypted timestamp: aes256-cts/73C6 [27242] 1456447062.215815: Encrypted timestamp (for 1456447062.215315): plain 301AA011180F32303136303232363030333734325AA1050203034913, encrypted F9A2E97E916FC14D141690E151A25DCC00168361179C7F0ACDA94C7F58F3D50429780A5608A6B8623E355F2A5BD676F6FA5272D38FD05C8B [27242] 1456447062.215942: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [27242] 1456447062.215948: Produced preauth for next request: 133, 2 [27242] 1456447062.215965: Sending request (257 bytes) to EXAMPLE.MY [27242] 1456447062.216010: Resolving hostname node1.example.my [27242] 1456447072.229254: Initiating TCP connection to stream 192.168.38.2:88 [27242] 1456447072.229655: Sending TCP request to stream 192.168.38.2:88 [27242] 1456447072.236955: Received answer (722 bytes) from stream 192.168.38.2:88 [27242] 1456447072.236974: Terminating TCP connection to stream 192.168.38.2:88 [27242] 1456447072.237080: Response was from master KDC [27242] 1456447072.237117: Processing preauth types: 19 [27242] 1456447072.237125: Selected etype info: etype aes256-cts, salt "s`GD^,#=cA:Vr9hD", params "" [27242] 1456447072.237131: Produced preauth for next request: (empty) [27242] 1456447072.237140: AS key determined by preauth: aes256-cts/73C6 [27242] 1456447072.237199: Decrypted AS reply; session key is: aes256-cts/2A71 [27242] 1456447072.237216: FAST negotiation: available [27242] 1456447072.237236: Initializing KEYRING:persistent:1000:1000 with default princ ttes...@example.my [27242] 1456447072.237275: Storing ttes...@example.my -> krbtgt/example...@example.my in KEYRING:persistent:1000:1000 [27242] 1456447072.237330: Storing config in KEYRING:persistent:1000:1000 for krbtgt/example...@example.my: fast_avail: yes [27242] 1456447072.237345: Storing ttes...@example.my -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY@X-CACHECONF: in KEYRING:persistent:1000:1000 [27242] 1456447072.237371: Storing config in KEYRING:persistent:1000:1000 for krbtgt/example...@example.my: pa_type: 2 [27242] 1456447072.237380: Storing ttes...@example.my -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.MY\@EXAMPLE.MY@X-CACHECONF: in KEYRING:persistent:1000:1000 *2. KRB5_TRACE=/dev/stderr kinit -kt keytab ttes...@example.my* [27248] 1456447236.144685: Getting initial credentials for ttes...@example.my [27248] 1456447236.147107: Looked up etypes in keytab: aes256-cts [27248] 1456447236.147255: Sending request (164 bytes) to EXAMPLE.MY [27248] 1456447236.147381: Resolving hostname node1.example.my [27248] 1456447246.161528: Initiating TCP connection to stream 192.168.38.2:88 [27248] 1456447246.161970: Sending TCP request to stream 192.168.38.2:88 [27248] 1456447246.164772: Received answer (337 bytes) from stream 192.168.38.2:88 [27248] 1456447246.164791: Terminating TCP connection to stream 192.168.38.2:88 [27248] 1456447246.164904: Response was from master KDC [27248] 1456447246.164943: Received error from KDC: -1765328359/Additional pre-authentication required [27248] 1456447246.164987: Processing preauth types: 136, 19, 2, 133 [27248] 145644724
Re: [Freeipa-users] Not able to get kerberos ticket from keytab
etype aes256-cts, salt "s`GD^,#=cA:Vr9hD", params "" [27248] 1456447246.165001: Received cookie: MIT [27248] 1456447246.165142: Retrieving ttes...@example.my from FILE:keytab (vno 0, enctype aes256-cts) with result: 0/Success [27248] 1456447246.165166: AS key obtained for encrypted timestamp: aes256-cts/0A17 [27248] 1456447246.165210: Encrypted timestamp (for 1456447246.164647): plain 301AA011180F32303136303232363030343034365AA1050203028327, encrypted C092E6C29FC1CD794625CF12162D18767A68D1728E6C2ADC1F50492D6605E039B664213C29767715E04B3CA8D97EBD691BBF40B76370C9FA [27248] 1456447246.165224: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [27248] 1456447246.165228: Produced preauth for next request: 133, 2 [27248] 1456447246.165239: Sending request (257 bytes) to EXAMPLE.MY [27248] 1456447246.165253: Resolving hostname node1.example.my [27248] 1456447256.178637: Initiating TCP connection to stream 192.168.38.2:88 [27248] 1456447256.179456: Sending TCP request to stream 192.168.38.2:88 [27248] 1456447256.184929: Received answer (167 bytes) from stream 192.168.38.2:88 [27248] 1456447256.184941: Terminating TCP connection to stream 192.168.38.2:88 [27248] 1456447256.185043: Response was from master KDC [27248] 1456447256.185065: Received error from KDC: -1765328353/Decrypt integrity check failed kinit: Password incorrect while getting initial credentials From the 2 trace I notice the return bytes on return from calling using keytab is only 167 bytes compare to 722 bytes. Does anybody know the reasons or could point me to where I could debug further? Thanks Hello! I don't know why it does not work with ktutil but I've find other way how to get keytab for a user: $ kinit ttester $ ipa-getkeytab -p ttes...@example.test -k ttester.keytab -e aes256-cts-hmac-sha1-96 $ kdestroy ttester $ kinit ttes...@example.test -kt ttester.keytab HTH, -- David Kupka -- 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] Recovering from data-only backup doesn't recover Kerberos keys properly
On 23/02/16 20:21, Marat Vyshegorodtsev wrote: Hi! I've been doing backups using the tool like this: ipa-backup --data --online I didn't want any configuration to be backed up, since it is managed from a chef recipe. However, when I tried to recover the backup to a fresh FreeIPA install, Kerberos (GSSAPI) broke — I can't authenticate myself anywhere using Kerberos: CLI, HTTP, etc. LDAP password-based authentication works alright. After some googling and reading through the mailing list, I followed this manual and updated all keytabs for all services — dirsrv, httpd, kadmin: http://www.freeipa.org/page/V3/Backup_and_Restore#Backup.2C_uninstall.2C_reinstall.2C_restore_JUST_the_LDAP_server Then it broke in a different way: for a correct session it says that my session is expired or just does nothing, for an incorrect password it responds with "password incorrect" (see screenshot). https://yadi.sk/i/WVe8u1_ZpNh3w For CLI it just says that the credentials are incorrect regardless of what credentials I provide. I suppose that all krbPrincipalKey fields are tied to some other encryption key that is not included in data-only backup. Could you please let me know how to regenerate krbPrincipalKey for all users or how to work around this issue? Best regards, Marat Hello Marat, I would say that this is expected. During freeipa-server installation all service and host kerberos keys are generated randomly, stored in Directory Server and in keytab accessible to the host/service. When you reinstall freeipa-server all keys are regenerated and no longer matches the ones stored in your backup. You can use ipa-getkeytab(1) with Directory Manager credentials to retrieve new keys but think it's not enough to make it work again. Hopefully, someone, who understand kerberos better will advice. -- David Kupka -- 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] Split backup actions in stop - backup - start commands
On 17/02/16 10:47, Matt . wrote: Hi David, I have tested your way out and it seems to be OK. The reason why I need this was is so I can perform a stop and ipa-backup before I start my backup to my backupserver. (pre-command). If I use ipa-backup directly it errors between the stop of ipa and the actual ipa backup. I need to check that out further. An ipactl start is not needed it seems as the ipa-backup command seems to start ipa at any time again. Do you understand/agree here ? Hello Matt, unfortunately I don't understand. The backup procedure AFAIK should work like this: # ipa-backup && rsync -r /var/lib/ipa/backup/ backup.example.test:/ipa/ You ca run it manually or place it into the crontab or use it in your orchestration system. It will backup the ipa server with necessary stop and start and then copy the new backup to the backup server. Still I don't see the need for stopping the server manually. ipa-backup calls "ipactl start" [0]. If you remove the else branch it will not start the server. [0 ]https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 HTH, David 2016-02-17 8:00 GMT+01:00 David Kupka <dku...@redhat.com>: On 16/02/16 20:26, Matt . wrote: Hi, I'm fugiring out if it's possible to strip the ipa start and stop from the backup method and actually do a fullbackup manually started. Any idea ? Thanks! Matt Hello Matt, you can perform data only backup where freeipa server is still running (ipa-backup --data --online). But IIUC you want full backup with stopped freeipa sever only want to manually run sequence ipactl stop ; ipa-backup ; ipactl start Could you please explain why do you need such behavior? Honestly, I'm unable to find use for this. There's no way how to do it without touching the code. If you don't mind editing code just remove two else branches starting on lines 293[0] and 316[1] in ipaserver/install/ipa_backup.py (on recent Fedoras located in /usr/lib/python2.7/site-packages/). With this change full backup will be performed on running server unless you stopped it before. It can result in inconsistent data in backup archive. [0] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n293 [1] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 -- David Kupka -- David Kupka -- 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] Logging configuration for ipa server
On 17/02/16 09:36, bahan w wrote:
Hello !
I send you this mail for a question about the kerberos logs on the ipa
server.
On the server, there are two configuration files :
- kdc.conf : for the server
- krb5.conf : for the client
In both of these files, we can put a logging section.
In this section, there is 3 parameters :
- default
- kdc
- admin
May I put the same values for both client and server or is it better to put
different values for the server part ?
BR.
Bahan
Hello Bahan,
looking into krb5.conf man page I don't see any logging section. I think
it should be enough to configure logging on the server (in kdc.conf).
Example:
User tries to perform kinit with nonexistent principal and receives error
$ kinit nonexistent
kinit: Client 'nonexist...@example.test' not found in Kerberos database
while getting initial credentials
Then admin can see this event in the kdc log on server:
Feb 17 10:10:35 vm-248.example.test krb5kdc[11350](info): AS_REQ (6
etypes {18 17 16 23 25 26}) 192.0.2.248: CLIENT_NOT_FOUND:
nonexist...@example.test for krbtgt/example.t...@example.test, Client
not found in Kerberos database
--
David Kupka
--
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] Split backup actions in stop - backup - start commands
On 16/02/16 20:26, Matt . wrote: Hi, I'm fugiring out if it's possible to strip the ipa start and stop from the backup method and actually do a fullbackup manually started. Any idea ? Thanks! Matt Hello Matt, you can perform data only backup where freeipa server is still running (ipa-backup --data --online). But IIUC you want full backup with stopped freeipa sever only want to manually run sequence ipactl stop ; ipa-backup ; ipactl start Could you please explain why do you need such behavior? Honestly, I'm unable to find use for this. There's no way how to do it without touching the code. If you don't mind editing code just remove two else branches starting on lines 293[0] and 316[1] in ipaserver/install/ipa_backup.py (on recent Fedoras located in /usr/lib/python2.7/site-packages/). With this change full backup will be performed on running server unless you stopped it before. It can result in inconsistent data in backup archive. [0] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n293 [1] https://git.fedorahosted.org/cgit/freeipa.git/tree/ipaserver/install/ipa_backup.py#n316 -- David Kupka -- 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] How to reference to IPA Server in Multi-Master Setup ?
On 25/01/16 12:08, Zeal Vora wrote: Thanks Petr. So if the domain is example.com, in DNS, what would be the IP associated with it ? As there are 2 master servers, each of them will have different IP address. On Mon, Jan 25, 2016 at 4:34 PM, Petr Spacek <pspa...@redhat.com> wrote: On 25.1.2016 10:47, Zeal Vora wrote: Hi I have setup a multi-master IPA and it seems to be working fine. The clients ( laptops and servers ) are not using the DNS of IPA. I was wondering, while configuring ipa-client, which server do I reference to when it asks the ipa-server hostname ? Both the master server has different hostnames. master1.example.com ( Master 1 ) master2.example.com ( Master 2 ) Specify only --domain option and do not use --server option at all. In will enable server auto-detection using DNS SRV records and you will not need to worry about adding/removing servers because all clients will automatically pick the new list up. -- 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 The '--domain' parameter is for client installer to form DNS request. Request that is sent is the same as one sent by this command: dig -t SRV _ldap._tcp. It then receiver list of records similar to this one: 100 0 389 100 0 389 Installer then goes through the list and checks if it's really FreeIPA server and first one that passes is used. When IP address is needed it can be resolved from the name included in SRV response. HTH, -- David Kupka -- 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] GID, groups and ipa group-show
On 14/01/16 22:09, Rob Crittenden wrote:
Prasun Gera wrote:
This is an old thread, but I can confirm that this is still an issue on
RHEL 7.2 + 4.2. This creates problems when there are roles associated
with groups, but group membership through GID is broken. I had migrated
all old NIS accounts into ipa. I then added the host enrollment role to
a particular group. Now, unless I add the users to the group explicitly,
they won't get the role, even if their gid is the same as the gid of the
group.
The user GIDNumber just sets the default group for POSIX. If you do
groups on the user I'll bet it shows correctly.
For the purposes of IPA access control, as you've seen, the user must
have a memberOf for a given group, either directly or indirectly.
rob
Exactly, but the question is, shouldn't IPA add this membership
automatically? (Of course, only in case IPA has group with this GID.)
David
On Mon, Aug 24, 2015 at 5:01 AM, David Kupka <dku...@redhat.com
<mailto:dku...@redhat.com>> wrote:
On 21/08/15 15:21, bahan w wrote:
Hello !
I contact you because I notice something strange with IPA
environment.
I created a group :
ipa group-add g1 --desc="my first group"
Then I created a user with the GID of g1
GID1=`ipa group-show g1 | awk '/GID/ {printf("%s",$2)}'`
ipa user-add --first=u1 --last=u1 --homedir=/home/u1
--shell=/bin/bash
--gidnumber=${GID1} u1
Then when I perform ipa group-show g1 command, I got the
following result :
###
Group name: g1
Description: my first group
GID:
###
Same for ipa user-show u1 :
###
User login: u1
First name: u1
Last name: u1
Home directory: /home/u1
Login shell: /bin/bash
Email address: u1@
UID:
GID:
Account disabled: False
Password: False
Member of groups: ipausers
Kerberos keys available: False
###
These 2 commands does not see u1 as a member of g1.
When I try the command id u1, I can see the group :
###
id u1
uid=(u1) gid=(g1) groups=(g1)
###
Is it the normal behaviour of these IPA commands ?
Best regards.
Bahan
Hello!
I'm not sure if this is intended and/or correct behavior or not.
Looking at /etc/passwd and /etc/group I see it behaves similarly in
a way.
You can have following entries in the aforementioned files
[/etc/group]
...
g1:x::
...
[/etc/passwd]
...
u1:x/home/u1:/bin/bash
...
Looking in /etc/group you can't see user 'u1' is member of group
'g1' but tools like id, groups, getent shows this information.
On the other hand it would be useful to show these "implicit"
members in group-show output.
Could you please file a ticket
(https://fedorahosted.org/freeipa/newticket)?
--
David Kupka
--
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
--
David Kupka
--
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] Why are some user's information not stored in the LDAP database?
On 16/10/15 15:26, Fujisan wrote: Hello, When I enter the email address, the phone number or the mailing address of ipa user 'smith' in the web ui "Identity/Users/smith", it does not appears in the output of ldapsearch. Sendmail can look into the ldap database and get the email address of a user and send mail to that user. Is it possible to add those info especially the email address in the ldap database? Regards, Fuji. Hello, I just tried and it worked as expected. Could you post your ldapsearch and its result? $ ldapsearch -D"cn=Directory Manager" -w Secret123 -h localhost -b cn=users,cn=accounts,dc=example,dc=test uid=tuser1 # extended LDIF # # LDAPv3 # base
Re: [Freeipa-users] Possible bug in ipa-replica-install/pkispawn - or maybe lib mismatch
On 23/09/15 10:35, Michael Lasevich wrote: Ok, I just went through process of migrating our IPA setup from 4.1.2 running on Fedora 20 (?? may have been 21) to 4.1.4 on CentOS 7 (MKosek Copr version) and run into a nasty bug. The replica-install crashes during CA configuration with something like: ''/usr/sbin/pkispawn' '-s' 'CA' '-f' '/tmp/tmpXX'' returned non-zero exit status 1 Skipping CA works, but I needed the CA. Upon digging into this, I found the issue appears to be in pki python, in file: /usr/lib/python2.7/site-packages/pki/system.py It looks like it makes a call to "/ca/rest/securityDomain/domainInfo" and gets an XML doc which it converts to JSON. Somehow it gets mangled before it looks at it. XML has outermost tag of "DomainInfo" - but JSON starts with "Subsystem" (one layer lower) - I am guessing JSON converted strips the "root" tag. I bypassed this by hardcoding id as "IPA" - but obviously that is sub-optimal Looking at Fedora box, it looks like the difference is in the version of PKI package that provides the lib - on Centos you get pki-base 10.1.2 (pki-base-10.1.2-7.1.el7.centos.noarch) - while on Fedore it was a 10.2 branch (and significantly different content in that file) Anyway, I saw some reports of this bug in searches and no answers - so I figured I would offer this pointer in (hopefully) the right direction. -M Hello Michael! Thanks for notifying us. Martin just updated the copr repository (https://copr.fedoraproject.org/coprs/mkosek/freeipa/) with newer version of PKI packages and I tested replication between Fedora 21 and CentOS 7.1 (both FreeIPA 4.1.4) and it works for me as expected. Could you please try it again? -- David Kupka -- 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] V6 and v4
On 13/09/15 16:33, Janelle wrote: Hello, I read something recently that if ip v6 is disable on a server this hurts performance in some way? Is there more info on this or did I misread it? Thank you ~J Hello Janelle, I do not now about any performance issue with disabled IPv6. Only case that came to my mind would be having records in DNS and not having corresponding IPv6 on that host but that is general misconfiguration. -- David Kupka -- 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] attempting to restore IPA
Hello Steven! I would like to help you but unfortunately I have no chance to guess what went wrong. To help us help you please report any issue in a way described on FreeIPA Troubleshooting page (http://www.freeipa.org/page/Troubleshooting). Most importantly we need the following: 1. Version of FreeIPA you are using. 2. Precise description of the problem. Stating that "password does not work" is not specific enough. Does "kinit admin" fails? With what error message? What is in kdc log? Or does SSH login fails? Does the login on client using the restored server work? 3. Steps that you did before the problem occurred. How was the mentioned backup created? Was the FreeIPA server reinstalled since the backup was taken? Was any password changed after the backup? Was any error/warning reported during the restore? 4. Logs. Please include at least iparestore.log and DS and Kerberos logs. Maybe some of the information I am missing here can be found in the thread you are responding to. But since you have changed the subject I assume you are solving another issue. In that case it makes sense to start completely new thread and provide all relevant information. Searching for them in older thread is not only time consuming but also may confuse us as they could be no longer valid and/or relevant. Do not take me wrong I am just trying to show you how to ask with bigger change of solving the issue for you in less time. Best regards, David On 10/09/15 01:41, Steven Jones wrote: So to restore IPA I tried, ipa-restore --data ipa-full-2015-09-10-10-28-11 and now I cannot loginopsie. The admin user password doesnt work and neither do my own accounts. NB I assume the flag --data restores the user data/HBAC rules etc? regards Steven -- 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] GID, groups and ipa group-show
On 21/08/15 15:21, bahan w wrote:
Hello !
I contact you because I notice something strange with IPA environment.
I created a group :
ipa group-add g1 --desc=my first group
Then I created a user with the GID of g1
GID1=`ipa group-show g1 | awk '/GID/ {printf(%s,$2)}'`
ipa user-add --first=u1 --last=u1 --homedir=/home/u1 --shell=/bin/bash
--gidnumber=${GID1} u1
Then when I perform ipa group-show g1 command, I got the following result :
###
Group name: g1
Description: my first group
GID: gid1
###
Same for ipa user-show u1 :
###
User login: u1
First name: u1
Last name: u1
Home directory: /home/u1
Login shell: /bin/bash
Email address: u1@MYDOMAIN
UID: uid1
GID: gid1
Account disabled: False
Password: False
Member of groups: ipausers
Kerberos keys available: False
###
These 2 commands does not see u1 as a member of g1.
When I try the command id u1, I can see the group :
###
id u1
uid=uid1(u1) gid=gid1(g1) groups=gid1(g1)
###
Is it the normal behaviour of these IPA commands ?
Best regards.
Bahan
Hello!
I'm not sure if this is intended and/or correct behavior or not.
Looking at /etc/passwd and /etc/group I see it behaves similarly in a way.
You can have following entries in the aforementioned files
[/etc/group]
...
g1:x:gid1:
...
[/etc/passwd]
...
u1:x:uid1:gid1::/home/u1:/bin/bash
...
Looking in /etc/group you can't see user 'u1' is member of group 'g1'
but tools like id, groups, getent shows this information.
On the other hand it would be useful to show these implicit members in
group-show output.
Could you please file a ticket (https://fedorahosted.org/freeipa/newticket)?
--
David Kupka
--
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] Different shell for different systems
On 18/08/15 20:47, Wood Peter wrote: Is it possible to setup different user shell for different systems? I want users to have /bin/bash on all systems but I'd like them to get /usr/bin/git-shell on some systems that serve git repositories. Any idea how to achieve that? Thank you, -- Peter Hello, I think that it should be possible with ID View (http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#ID_Views) but I'm not familiar with it. -- David Kupka -- 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] time restricted access
On 13/08/15 17:01, Marcelo Roccasalva wrote: Hello, I've installed freeIPA 4.1.0 under CentOS 7 and I need to restric authentication to one or more time ranges but I failed to find such a configuration... TIA Hello, you're probably looking for Time-Based Account Policies. This is currently WIP, you can find more on freeipa-devel list. -- David Kupka -- 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] IdM Password Expiration
On 04/08/15 17:01, Robert Locke wrote: Hey folks, I have been using the following to adjust the Password Expiration of accounts in IdM/IPA: echo $ADMIN_PASS | kinit admin echo -e dn: uid=rheluseri,cn=users,cn=accounts,dc=example,dc=com\nchangetype: modify \nreplace: krbPasswordExpiration\nkrbPasswordExpiration: 2030010100Z \n | ldapmodify -x -D 'cn=Directory Manager' -w $ADMIN_PASS This has worked nicely for me. My new problem is that the admin account itself expires after 90 days. I thought since ldapsearch does show the admin account, that simply substituting the uid might work. echo -e dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com \nchangetype: modify\nreplace: krbPasswordExpiration \nkrbPasswordExpiration: 2030010100Z\n | ldapmodify -x -D 'cn=Directory Manager' -w $ADMIN_PASS My attempts to adjust the admin account in this similar fashion have been not surprisingly unsuccessful. Suggestions/pointers? --Rob Hello, I just tried to set krbPasswordExpiration attribute for admin and it worked as expected: $ ipa user-show admin --all dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com User login: admin ... krbpasswordexpiration: 2020010100Z ... $ echo -e dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com\nchangetype: modify\nreplace: krbPasswordExpiration\nkrbPasswordExpiration: 2030010100Z\n | ldapmodify -x -D 'cn=Directory Manager' -w $DM_PASS modifying entry uid=admin,cn=users,cn=accounts,dc=example,dc=com $ ipa user-show admin --all dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com User login: admin ... krbpasswordexpiration: 2030010100Z ... Could you provide more information about what is failing? Only thing that comes to my mind is that you're using $ADMIN_PASS variable where Directory Manager password is required but I know it's just name of the variable. -- David Kupka -- 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] Another Migration from 3.0 (CentOS 6.6) to 4.1 (CentOS 7.1)
/Jul/2015:17:25:50][TP-Processor2]: GroupAccessEvaluator: evaluate: uid null [28/Jul/2015:17:25:50][TP-Processor2]: evaluated expression: group=Enterprise RA Administrators to be false [28/Jul/2015:17:25:50][TP-Processor2]: GroupAccessEvaluator: evaluate: uid null [28/Jul/2015:17:25:50][TP-Processor2]: evaluated expression: group=Enterprise OCSP Administrators to be false [28/Jul/2015:17:25:50][TP-Processor2]: GroupAccessEvaluator: evaluate: uid null [28/Jul/2015:17:25:50][TP-Processor2]: evaluated expression: group=Enterprise TKS Administrators to be false [28/Jul/2015:17:25:50][TP-Processor2]: SignedAuditEventFactory: create() message=[AuditEvent=AUTHZ_FAIL][SubjectID=$NonRoleUser$][Outcome=Failure][aclResource=certServer.clone.configuration.UpdateNumberRange][Op=modify] authorization failure ... Do you guys know which certificate is the one that's failing and where else to look at to fix this problem? Thanks so much for any help you can provide! Guillermo Hello! The problem is in pki-* packages. The old version that is used with freeipa-3.0 does not have REST API and the one that is used in freeipa-4.1 does not expect that. The issue is fixed in pki 10.2.6 but I'm not sure if it is available in CentOS, yet. -- David Kupka -- 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] Primary certificates
On 13/07/15 16:05, Janelle wrote: Good morning, I was wondering, I install my servers with the self-signed certs. Now my management wants me to use official certificates. Is there an easy/recommended way to swap out all the certificates on all the servers? Especially with 16 servers, just trying to figure out if this is something I could script with PSSH or similar in order to do them all at once. Does it matter the order? Thank you ~Janelle Hello! Yes, there is an easy way: 1.Run ipa-cacert-manage renew --external-ca on one of CA masters (first ipa-server installed or any replica installed with --setup-ca). This will generate csr you need to get signed by your CA. 2. Then run ipa-cacert-manage renew --external-cert-file signed certificate --external-cert-file your ca certificate This will update the IPA CA certificate in LDAP. 3. Then you need to run ipa-certupdate on all ipa servers and clients to distribute the new certificate. -- David Kupka -- 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] freeipa sudden stop
On 30/06/15 05:17, Umarzuki Mochlis wrote: Every once in a week suddenly IPA service would failed and only realized when zimbra that using authentication with it failed during user log in. So I had to type in below commands one by one each time this happened. systemctl start dirsrv@DOMAIN-COM.service systemctl start krb5kdc.service systemctl start kadmin.service systemctl start ipa_memcached.service systemctl start httpd.service # cat /etc/redhat-release Fedora release 18 (Spherical Cow) # rpm -qa | grep freeipa freeipa-admintools-3.1.0-2.fc18.x86_64 freeipa-server-3.1.0-2.fc18.x86_64 freeipa-client-3.1.0-2.fc18.x86_64 freeipa-server-selinux-3.1.0-2.fc18.x86_64 freeipa-python-3.1.0-2.fc18.x86_64 I was told this this IPA server is a master IPA. I could not find crash log in /var/log/messages other then when I failed to start certain services or service ipa start Any idea where I should exactly be looking in to? Log messages attached. Hello! The issue seems quite annoying. Could you please provide more info? Do you have one freeipa master or more replicas? If not do you experience this issue only on one of them? According to the logs it looks like starting of pki-tomcatd fails and therefore ipactl start fails. Could you run # ipactl start -d and post its output? Also starting individual services is not a good idea as you can forget to start some (you actually did :-) -- David Kupka -- 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] FreeIPA cluster shutdown sequence
On 05/04/2015 07:09 AM, Thomas Lau wrote: Hi All, We got a power maintenance soon, so all servers need to shutdown. Is there have a shutdown / starting up procedure for FreeIPA cluster? We are currently running two node cluster. Hello, as I responded a month ago (https://www.redhat.com/archives/freeipa-users/2015-April/msg00016.html) there is no special procedure. You just turn the servers off before the power outage and then turn them back on. -- David Kupka -- 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] Access to IPA Web-UI with different domain names
On 04/27/2015 06:06 PM, David Dimovski wrote: Hi Folks, does somebody have a best practice, how to access the IPA Web-UI with different domain names? Example: Our IPA 4.1 have two different IPs (extern and intern) with two domain names. The web gui is only accessible from the domain name, which IPA was registered with (intern domain name). When trying to access with the extern domain name, IPA is rewriting to the intern domain name. After disabling the rewriting, the web ui is accessible from the two domain names, but the login is not possible from the extern domain name (only intern domain name), getting the following error: Logout session expired. Does sombody has a idea or a clue? Many thanks in advance! Best regards David Hello! IIUC this is not something FreeIPA supports. When you deploy FreeInPA server it is tied to a domain specified during installation. I think you need to decide whether your FreeIPA domain is internal or external. If it's internal it is inaccessible from outside and you need to first connect to the internal network (e.g. use VPN) and then connect to FreeIPA server. If it's external then everything works as expected. -- David Kupka -- 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] Found new problem after 3.3 - 4.1 update
On 04/20/2015 12:00 PM, Alexander Frolushkin wrote: Hello! We found our host enrollment role does not work after ipa server update. Now user having this role get this error: Joining realm failed: No permission to join this host to the IPA domain. Maybe now we need to add some addition permissions to this role, can someone to point out which permissions is required to add new host to domain? WBR, Alexander Frolushkin Cell +79232508764 Work +79232507764 ?? ? ? ? ? ??? ?? ???, ??? ??? ??. ? ? ? ??? ??, ??? ?? ? ??? ???-, ? ?. ?? ?? ??? ? ?, ?? ?, ?, ??? ??? ??? ?? ? ??? ??? ? ? ? ?. ?? ??? ? , ??, ??? ??? ?? ? ??? ?? ?? ? ? ? ? ??? ? ? ??. 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 Hello! This thread seams to solve similar issue: https://www.redhat.com/archives/freeipa-users/2013-January/msg00153.html -- David Kupka -- 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] Power down all FreeIPA servers
On 04/01/2015 10:19 AM, Thomas Lau wrote: Hi all, we are going to have power maintenance and needed to shutdown two core FreeIPA server. Is there have any sequence to shutdown and power on FreeIPA server? Anything I need to aware of? Hello, IFAIK there is no recommended Trick. You can turn them off and on normaly (with system or using ipactl stop/start) and after they start again the replication process should continue. -- David Kupka -- 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] Minimum rights to enrol a client
On 03/20/2015 09:16 AM, Andrew Holway wrote: Hello, I'd like to find our what the minimum role would be to allow a user to join a new client to freeipa. Currently our enrol command looks like: ipa-client-install --force-join --enable-dns-updates -U -p admin -w : Thanks, Andrew Hello! AFAIK there is 'Host Enrollment' privilege created during IPA server installation. You need to create new role and add this privilege to the newly created role. The role can then be assigned to any user or group. User with this privilege have enough permissions to enroll a host to IPA domain. -- David Kupka -- 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] Adding external CA
On 03/12/2015 10:37 AM, crony wrote: Hi FreeIPA Users, I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would like to change the self-sign CA to the external CA Do you have any step by step document for do it correctly on 4.1 version? /lm Hello! I'm not aware of this being documented but fortunately this can be done in 3 easy steps: 1. # ipa-cacert-manage renew --external-ca 2. Let CA of your choice sing the CRL produced in step 1. 3. # ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate -- David Kupka -- 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] chrony support
Hello Bryan, I'm currently working on this. This feature should be available in freeipa-4.2. -- David Kupka On 02/13/2015 01:25 PM, Bryan Pearson wrote: One of our IPA servers, is in a virtualized environment and is continuously losing time, resulting in invalid credentials and breaking replication. We are interested in using chrony instead of ntpd, while ipa start up and use chrony instead of ntp? Bryan -- 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-Server v3.0 Replication Broken
On 01/29/2015 02:43 PM, Auerbach, Steven wrote: We have a pair of IPA Servers for our network. Our servers are Oracle Linux 6 x86_64 with the ipa-server.3.0.X packages [up to date as distributed by Oracle Linux]. Recently we noticed that the master (IPA01) is replicating fine to the designated replicant. But changes that are made on the replicant do not get back to the master. This is true when ipa-clients register (if the registration script grabs the replicant for registration then the host enrollment and DNS will not make it back to the master. This is true when users make a password change. If the password process grabs the master then replication to the replicant is fine, but if the change process grabs the replicant it will not make it back to the master. Then the user login is broken. This is true when, in the IPA Admin Web Interface we delete a host entry or DNS record. If done on the master the change replicates to the replicant. If the change is made on the replicant it does not make it to the master. We have not found anything in the documentation that helps us understand where to proceed or what to do to diagnose the replication problem. We have tried removing the replicant from the IPA server configuration and powering off the box, creating a new server and reconstructing a new replica on that new server. The problem persists. We suspect the issue lies in some configuration somewhere on the master, but know not where to go next. Anyone have a similar experience and overcome it? We will take any advice we can get! With appreciation and respect; Steven Auerbach Systems Administrator State University System of Florida Board of Governors 325 West Gaines Street Tallahassee, Florida 32399 (850) 245-9592 | Fax (850) 245-0419 www.flbog.edu [BOG-wordmark-wideFOR EMAIL-color] Hi, this looks similar to: https://www.redhat.com/archives/freeipa-users/2015-January/msg00331.html and https://fedorahosted.org/freeipa/ticket/4807 Did you try to raise the nsslapd-sasl-max-buffer-size? -- David Kupka -- 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
