[Freeipa-users] ipa-client-install generates bad sssd.conf

[Harald Dunkel]

Hi folks,

running freeipa client 4.3.2-5 and sssd 1.15.0-3 on Debian
Stretch ipa-client-install creates a bad sssd.conf file, e.g.

[domain/example.com]

cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = example.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ldap_tls_cacert = /etc/ipa/ca.crt
ipa_hostname = stretch1.vs.example.com
chpass_provider = ipa
ipa_server = _srv_, ipa1.example.com
dns_discovery_domain = example.com
[sssd]
domains = example.com
services = sudo
[sudo]


Esp. the services for nss, pam and ssh are not setup. Is this
as expected?


Every helpful comment is highly appreciated.
Harri

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] renewing cert and migrating free-ipa 3.1

[Umarzuki Mochlis]

After httpd failed to start even with "NSSEnforceValidCerts off" in
/etc/httpd/conf.d/nss.conf
It used to work for a while since we use this only for zimbra but
today it won't start anymore.

We are not using commercial certs, so which steps should I follow to
renew certs?

It seems CA has expired more than 2 weeks ago.

#  ipa-getcert list
Number of certificates and requests being tracked: 7.
Request ID '20130112120232':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl
failed to execute the HTTP POST transaction, explaining:  Peer's
Certificate has expired.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-DOMAIN-COM-MY/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-DOMAIN-COM-MY',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=DOMAIN.COM.MY
subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY
expires: 2016-12-16 16:18:27 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_dirsrv
DOMAIN-COM-MY
track: yes
auto-renew: yes
Request ID '20130112120734':
status: CA_UNREACHABLE
ca-error: Server failed request, will retry: -504 (libcurl
failed to execute the HTTP POST transaction, explaining:  Peer's
Certificate has expired.).
stuck: yes
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=DOMAIN.COM.MY
subject: CN=ipa.domain.com.my,O=DOMAIN.COM.MY
expires: 2016-12-16 16:18:27 UTC
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/lib64/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes

# rpm -qa | grep ipa
freeipa-admintools-3.1.0-2.fc18.x86_64
freeipa-server-3.1.0-2.fc18.x86_64
libipa_hbac-python-1.9.3-1.fc18.x86_64
python-iniparse-0.4-6.fc18.noarch
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
libipa_hbac-1.9.3-1.fc18.x86_64

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Push authentication policy using IPA

[William Muriithi]

Hello,

Is there currently any way one can force IPA clients (Gnome and KDE)
to authenticate users before one can have Gnome based services like
browser and such?

I am looking for something similar to windows GPO that one can publish
to force password authentication after restart or after a certain time
expire without any users activity.

If not, would anyone have an way of controlling  RHEL based system
policies in a central way?  Any pointer would be appreciated

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

Re: [Freeipa-users] LDAP based autofs map redundancy

[Jakub Hrozek]

On Thu, Mar 02, 2017 at 03:28:38PM -0500, William Muriithi wrote:
> Afternoon,
> 
> 
> I have noticed that even when a network has two IPA for redundancy,
> autofs don't seem to be able to take advantage of the remaining IPA
> should one of the IPA goes down.
> 
> Is this a know issue with LDAP based maps or is it a configuration
> that need to be adjusted. By the way, only about half of the systems
> are affected and I have noticed they have this on sssd.conf
> 
> 
> ipa_server = _srv_, hydrogen.eng.example.com
> 
> It does look though like kerberos is not affected as all systems can
> authenticate fine, so looks like its autofs issue alone
> 
> This is the error I am noticing on the logs.
> 
> Mar  2 14:18:29 platinum automount[2887]: key "brad" not found in map 
> source(s).
> Mar  2 14:19:18 platinum automount[2887]: bind_ldap_simple:
> lookup(ldap): Unable to bind to the LDAP server: (default), error
> Can't contact LDAP server
> Mar  2 14:19:21 platinum automount[2887]: bind_ldap_simple:
> lookup(ldap): Unable to bind to the LDAP server: (default), error
> Can't contact LDAP server

I guess /etc/nsswitch.conf uses ldap for automount and not sssd?

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] LDAP based autofs map redundancy

[William Muriithi]

Afternoon,


I have noticed that even when a network has two IPA for redundancy,
autofs don't seem to be able to take advantage of the remaining IPA
should one of the IPA goes down.

Is this a know issue with LDAP based maps or is it a configuration
that need to be adjusted. By the way, only about half of the systems
are affected and I have noticed they have this on sssd.conf


ipa_server = _srv_, hydrogen.eng.example.com

It does look though like kerberos is not affected as all systems can
authenticate fine, so looks like its autofs issue alone

This is the error I am noticing on the logs.

Mar  2 14:18:29 platinum automount[2887]: key "brad" not found in map source(s).
Mar  2 14:19:18 platinum automount[2887]: bind_ldap_simple:
lookup(ldap): Unable to bind to the LDAP server: (default), error
Can't contact LDAP server
Mar  2 14:19:21 platinum automount[2887]: bind_ldap_simple:
lookup(ldap): Unable to bind to the LDAP server: (default), error
Can't contact LDAP server

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

[Freeipa-users] Kerberos autheticated NFS issue

[William Muriithi]

Afternoon.

I have noticed below errors on a RHEL 6.8 NFS client that is using a
IPA 4.4 for authentication.

On some system, this error show up a lot.  The connection is fine
according to nmap, but the logs imply there is issue with the
connection. What are some of the reason that can trigger the
particular error on NFS system?

Mar  2 11:50:51 manganese rpc.gssd[8336]: WARNING: can't create tcp
rpc_clnt to server plutonium.eng.example.com for user with uid 0: RPC:
Remote system error - No route to host
Mar  2 11:50:51 manganese rpc.gssd[8336]: WARNING: can't create tcp
rpc_clnt to server plutonium.eng.example.com for user with uid 0: RPC:
Remote system error - No route to host
Mar  2 11:52:23 manganese rpc.gssd[8336]: WARNING: can't create tcp
rpc_clnt to server bromine.eng.example.com for user with uid 0: RPC:
Remote system error - No route to host
Mar  2 11:52:23 manganese rpc.gssd[8336]: WARNING: can't create tcp
rpc_clnt to server bromine.eng.example.com for user with uid 0: RPC:
Remote system error - No route to host
Mar  2 11:52:26 manganese rpc.gssd[8336]: WARNING: can't create tcp
rpc_clnt to server iodine.eng.example.com for user with uid 0: RPC:
Remote system error - No route to host

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

Re: [Freeipa-users] Switch sudoers to IPA

[Jakub Hrozek]

On Thu, Mar 02, 2017 at 09:50:41PM +0530, deepak dimri wrote:
> Hi Jakub, Actually that is what i am doing. i am creating the user with
> same UID in IPA and then if i delete the user locally then i can
> authenticate via IPA. Is there anyway i can do this without deleting the
> user? This is just to use the same GID and avoid recreation of
> home/directories.

I think you'd need to modify the PAM stack to keep going even if
authentication against pam_unix fails. I /think/ (but haven't tested )
that modifying the lines that deal with pam_unix/pam_sss like this:

auth [default=2 success=ok] pam_localuser.so
auth sufficient pam_unix.so nullok try_first_pass
auth [success=done ignore=ignore default=die] pam_sss.so use_first_pass

could work. The other lines in the PAM auth stack and all the other
stacks should be left intact.

(Please keep a root shell around if you're going to tinker with PAM
settings and preferably try this out on a test box first.)

-- 
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] documentation or example of using S42U for NFS

[Charles Hedrick]

The repo is https://github.com/clhedrick/kerberos.git. There’s a README.md, and 
man pages for the individual programs. While I’m currently using these 
programs, we haven’t fully rolled out Kerberos yet. As we do, I expect we’ll 
want to add more features. (E.g. kgetcred / credserv need to support redundant 
servers.)

When free ipa implements all planned features, kgetcred / credserv may not 
longer be needed. Rnewd and skinit still will be (though skinit should be 
modified to use “kinit -n” rather than “kgetcred -a"

On Mar 1, 2017, at 5:47 PM, Orion Poplawski 
> wrote:

If you ever get this into a repository, I'd love to see it.  Thanks.

On 01/17/2017 07:44 PM, Charles Hedrick wrote:
Instructions like that are several places. But NFS is different, and I believe 
the configuration would be different from other services.

I’ve given up on this approach, and have written my own utilities. I’ve 
actually got three. The first two assume that users who want to do cron jobs on 
a machine register a keytab for that machine on a secure system. I don’t want 
to put the actual keytab on the machine where the user is running, because if 
someone can become root, they can take the keytab and use it anywhere. (I’m in 
a computer science dept with systems run by faculty and grad students; also 
systems in public labs.)

So instead, I allow users to register that they want to do cron on a specific 
machine by putting a keytab on a secure server, associated with their username 
and the hostname. I expect to write a web app to set that up.

Credserv runs on the machine with the keytabs. It accepts a request from a 
server, authenticated using the host’s host key (i.e. /etc/krb5.keytab), with a 
username in the request. If the user has registered a keytab for that host, 
credserv returns a credential, locked to that IP address, with forwarding off.

Kgetcred is the client side. It runs setuid root (so it can read 
/etc/krb5.keytab), though it drops privs as quickly as possible. It creates a 
credentials cache for the user from the credentials returned from credserv.

This gives the best granularity of control I can come up with.

There’s a third utility in the family: renewd. It gets the uids of all current 
processes, and renews credentials for all of the users. It’s more complex than 
you’d expect because a normal renewal (as in kinit -R or kstart) leaves a brief 
period of time when the credentials cache is unusable. This can result in NFS 
failing. I use a special approach that depends upon the details of the KEYRING 
implementation. It should be free of race conditions for NFS. If desired, a 
different approach to avoid race conditions could be used for caches located in 
/tmp. I haven’t written that code but there’s a comment in the source outlining 
it.

I’ll be creating a git repository for the code.


On Jan 17, 2017, at 6:41:13 PM, Orion Poplawski 
> wrote:

On 01/09/2017 09:52 AM, Charles Hedrick wrote:
Various documentation suggests that it is possible for Gssproxy to get tickets 
for users who need to use NFS. This is a possible way to handle things like 
cron jobs.

However while a gssproxy.conf example is given, there’s no sign of what needs 
to be done in freeipa to authorize it. I tried following instructions for LDAP 
access, but it doesn’t work. NFS seems to use a different, two-stage method for 
getting credentials, so that’s not a surprise. There are, not surprisingly, no 
useful error messages even with logging turned all the way up.



I'm interested in this as well.  All I've been able to find so far is:

https://vda.li/en/posts/2013/07/29/Setting-up-S4U2Proxy-with-FreeIPA/

haven't tried anything.

--
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com



--
Orion Poplawski
Technical Manager  720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane   or...@nwra.com
Boulder, CO 80301   http://www.nwra.com

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

Re: [Freeipa-users] documentation or example of using S42U for NFS

[Charles Hedrick]

Thanks. That’s what I was originally looking for. However since asking it I 
realized that doing it without further limitations defeats the purpose of using 
Kerberos in the first place, since it means that anyone who becomes the user in 
Linux can access their files.

I’m trying to make sure that users can decide which machines they’re willing to 
expose to access without a credential. In our department we have shared 
systems, which we run, student labs, which we run but that are not physically 
secure, and user-maintained machines. We’d like to say that normally no one can 
access your files without having your credentials. So if someone manages to 
become root on one system they don’t suddenly have access to everyone’s files.

We have to relax that where users need to run cron jobs. But I’d like that 
relaxation to be in a controlled way. That is, I want the user to have to say 
that on a specific machine it’s possible to access their files based just on 
being their uid. But that only applies to the specific user on the specific 
machine. That at least restricts exposure.

If S42U is turned on for NFS as described below, then anyone who becomes root 
can become any user, and then access any user’s files.

The design documentation says:

"The ACL system also provides a means of limiting which user's a ticket may be 
obtained for using the ipaAllowToImpersonate attribute. This is not 
implemented."

There’s no sign of this feature in the command line tools, so I assume it’s 
still not implemented. Until it is I don’t think that will do what I need.

Kgetcred, however, will do the job.

On Mar 1, 2017, at 9:29 PM, Greg > 
wrote:

I've been at this as well for a while now, and managed to make it work for my 
NFS needs (automounting user homes with password-less logons).

Whether and how this would apply to cron or other services, I don't know yet, 
but presumably would/should work in a similar manner.

My env:

$ lsb_release -d
Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)
$ rpm -q ipa-server
ipa-server-4.4.0-14.el7_3.4.x86_64
$ ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

This is what worked for me in the end:

1. Create "nfs/nfsserver.dom@dom.com" 
service, and add to NFS server's /etc/krb5.keytab.

2. Create IPA "servicedelegation" rule/targets, so that they look like so:

$ ipa servicedelegationrule-show ipa-nfs-delegation
  Delegation name: ipa-nfs-delegation
  Allowed Target: ipa-nfs-delegation-targets
  Member principals: host/nfsclient.dom@dom.com

$ ipa servicedelegationtarget-show ipa-nfs-delegation-targets
  Delegation name: ipa-nfs-delegation-targets
  Member principals: nfs/nfsserver.dom@dom.com

Only niggle here is IPA CLI didn't let me add "host/..." principal to the rule, 
or perhaps there's a default LDAP ACI of some sort and it requires a 
privilege/permission to be granted. The "ipa servicedelegationrule-add-member 
..." command simply says "no such entry" for "host/..." type principals. Maybe 
IPA folks can comment.

I force added it to the delegation rule via LDAP instead using this ldif:

dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com
changetype: modify
add: memberPrincipal
memberPrincipal: 
host/nfsclient.dom@dom.com

The "nfs/..." principal can be added using CLI "ipa 
servicedelegationtarget-add-member ..." just fine.

3. Allow the "nfsclient" host to impersonate users:

$ ipa host-mod nfsclient.dom.com 
--ok-to-auth-as-delegate=true

4. On the "nfsclient" machine, add "impersonate = true" line in the 
"[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf.

5. Restart nfs/gssproxy/rpc services on client and server (it's probably just 
gssproxy on the client that needs a kick, but just to be sure). I was also 
religiously doing "sss_cache -E" for good measure, unmounting anything that got 
mounted, and clearing /var/lib/gssproxy/clients of all caches, to start as 
cleanly before each attempt at user logon. Obv make sure the user does not have 
an existing/valid ticket in their own cache ("kdestroy -A" as the user), 
otherwise it'll just mount successfully without delegation.

I think that's it, I've messed about with the config for a long time and in 
many places, so there's a small chance there's something else that I did and 
don't remember. Gssproxy config on "nfsserver" is vanilla, as are my sssd.confs 
and krb5.confs on both machines, can't think of much else that I might've 
changed for now.

So my IPA automount config now mounts users' home dirs on the "nfsclient", 
without any tickets or keytabs from users.

There's also a "krb5_principal" option available in gssproxy.conf - I tried to 
set that to "nfs/nfscli...@dom.com" in 
"[service/nfs-client]" section on the "nfsclient" machine, to try and force 

Re: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening

[Chris Herdt]

On Thu, Mar 2, 2017 at 10:06 AM, Martin Basti  wrote:

>
>
>
> On 02.03.2017 16:55, Chris Herdt wrote:
>
>
>
> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti  wrote:
>
>>
>>
>> On 02.03.2017 01:07, Chris Herdt wrote:
>>
>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a
>> FreeIPA 3.0.0 master on CentOS 6.8 following the steps at
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterp
>> rise_Linux/7/html/Linux_Domain_Identity_Authentication_and_P
>> olicy_Guide/upgrading.html
>>
>> At this step:
>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir
>> /var/lib/ipa/replica-info-replicaname.example.com.gpg
>>
>> I get the error:
>> ERROR cannot connect to 'ldaps://master.example.com'
>>
>> I ran ipa-replica-conncheck and found that port 636 is not accessible:
>> Port check failed! Inaccessible port(s): 636 (TCP)
>>
>> The port is not blocked. I'm wondering where in the configuration for
>> FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a
>> way I can specify to use port 389 for setting up the replica.
>>
>> Thanks!
>>
>> --
>> Chris Herdt
>> Systems Administrator
>>
>>
>>
>> Hello,
>> this is known issue only in FreeIPA 4.4.x, this will be fixed  in next
>> minor update which should be released soon to RHEL7.3 (I don't know how
>> fast it will be in Centos)
>>
>> so you can wait, or enable it manually (not nice)
>>
>> sorry for troubles
>> Martin
>>
>
>
> Thanks for the reply! Before attempting this in my production environment,
> I had set up a similar configuration in a test environment (FreeIPA 3.0.0
> master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the
> ipa-replica-install went fine. I assumed this was an issue with my FreeIPA
> 3.0.0 production server.
>
> To enable the fix manually, I'm assuming I'd need to install FreeIPA from
> source on the intended replica? If I download the 4.4.3 release from
> https://pagure.io/freeipa/releases, will that be sufficient?
>
> Sorry,
> I probably misread what you wrote, I thought that port is closed on
> replica, but now I see that port is closed on 3.3.0 master, so this is
> something different. I'm not aware of any issue on 3.3.0 that should cause
> this.
>
> Could you check your configuration on 3.3.0 master? Is port opened on
> master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on
> master?
>
> Martin
>

When I compare the errors file on my production environment and my test
environment, I do note that the LDAPS entry is missing from my production
environment:

production:
[01/Mar/2017:17:30:07 -0600] - slapd started.  Listening on All Interfaces
port 389 for LDAP requests
[01/Mar/2017:17:30:07 -0600] - Listening on
/var/run/slapd-PROD-EXAMPLE-COM.socket
for LDAPI requests

test:
[28/Feb/2017:13:37:50 -0600] - slapd started.  Listening on All Interfaces
port 389 for LDAP requests
[28/Feb/2017:13:37:50 -0600] - Listening on All Interfaces port 636 for
LDAPS requests
[28/Feb/2017:13:37:50 -0600] - Listening on
/var/run/slapd-TEST-EXAMPLE-COM.socket
for LDAPI requests

I'm not sure why it is missing though. Which config file(s) should I be
checking?


-- 
Chris Herdt
Systems Administrator
-- 
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] Switch sudoers to IPA

[deepak dimri]

Hi Jakub, Actually that is what i am doing. i am creating the user with
same UID in IPA and then if i delete the user locally then i can
authenticate via IPA. Is there anyway i can do this without deleting the
user? This is just to use the same GID and avoid recreation of
home/directories.

Many Thanks for your response!

Regards,
Deepak

On Thu, Mar 2, 2017 at 8:40 PM, Jakub Hrozek  wrote:

> On Thu, Mar 02, 2017 at 07:09:41PM +0530, deepak dimri wrote:
> > Hi List,
> >
> > I have sudo and normal users accessing linux systems using their private
> > key without IPA. I have IPA fully functioning and now i want to switch
> the
> > users from local file login to IPA.
> >
> > Any new user i create in IPA can SSH into ipa client jump boxes fine. I
> > want to know how i can migrate existing local sudoers users to IPA.  This
> > is what i have done to achieve this:
> >
> > 1-  Created a new user in IPA with the same name as i have in Jumpbox.
> > 2 - Added the public key of that user in IPA.
> > 3-  Added the user to jumpbox_usergroup as my sshd.conf forces the users
> of
> > this group to authenticate against the pam/sssd
> >
> > Now when i try to ssh into jumpbox using as i was doing before i still
> logs
> > into the jumpbox via unix pam and not IPA.  What should i be doing so
> that
> > the "existing" local unix users can login via IPA?
>
> But do you need to keep the local users around? Why not create the IPA
> user with the same UID as the local user and remove the local user?
>
> Typically, if there is a user both in the local files and a remote
> source, the system (as configured in nsswitch.conf) would first return
> the local user and the PAM stack then only authenticates this user using
> pam_unix.so
>
> --
> Manage your subscription for the Freeipa-users mailing list:
> https://www.redhat.com/mailman/listinfo/freeipa-users
> Go to http://freeipa.org for more info on the project
>
-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Issue with ipa-client-install v4.4.0

[Mick Love]

Hi, I seem to having some issue trying to install the IPA client (version
4.4.0) on Centos 7 using DNS.

I can get a working install by issuing the —server flags, but I would
rather do it using SRV so we can issue the command via salt to multiple
servers, and should we add another replicant. We will only need to update
the SRV records rather than updating all our client servers.


I am running this command,


$>ipa-client-install --force-ntpd  --mkhomedir --principal admin --realm=
UK.INTERNAL.MYDOMAIN.COM --domain uk.internal.mydomain.com --unattended -w
superhard


But I keep getting this.


Discovery was successful!

Client hostname: portalwaf2.uk

Realm: UK.INTERNAL.MYDOMAIN.COM

DNS Domain: freeipa.uk.internal.mydomain.com

IPA Server: ipa1.uk.internal.mydomain.com

BaseDN: dc=uk,dc=internal,dc=mydomain,dc=com


Synchronizing time with KDC...

Attempting to sync time using ntpd.  Will timeout after 15 seconds

Successfully retrieved CA cert

Subject: CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM

Issuer:  CN=Certificate Authority,O=UK.INTERNAL.MYDOMAIN.COM

Valid From:  Fri Feb 17 12:09:04 2017 UTC

Valid Until: Tue Feb 17 12:09:04 2037 UTC


Enrolled in IPA realm UK.INTERNAL.MYDOMAIN.COM

Created /etc/ipa/default.conf

New SSSD config will be created

Configured sudoers in /etc/nsswitch.conf

Configured /etc/sssd/sssd.conf

Configured /etc/krb5.conf for IPA realm UK.INTERNAL.MYDOMAIN.COM

trying https://ipa1.uk.internal.mydomain.com/ipa/json

Traceback (most recent call last):

  File "/usr/sbin/ipa-client-install", line 3128, in 

sys.exit(main())

  File "/usr/sbin/ipa-client-install", line 3109, in main

rval = install(options, env, fstore, statestore)

  File "/usr/sbin/ipa-client-install", line 2818, in install

api.finalize()

  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 707, in
finalize

self.__do_if_not_done('load_plugins')

  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 422, in
__do_if_not_done

getattr(self, name)()

  File "/usr/lib/python2.7/site-packages/ipalib/plugable.py", line 585, in
load_plugins

for package in self.packages:

  File "/usr/lib/python2.7/site-packages/ipalib/__init__.py", line 919, in
packages

ipaclient.remote_plugins.get_package(self),

  File
"/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/__init__.py",
line 118, in get_package

plugins = schema.get_package(server_info, client)

  File
"/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line
543, in get_package

schema = Schema(client)

  File
"/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line
387, in __init__

fingerprint, ttl = self._fetch(client, ignore_cache=read_failed)

  File
"/usr/lib/python2.7/site-packages/ipaclient/remote_plugins/schema.py", line
413, in _fetch

client.connect(verbose=False)

  File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in
connect

conn = self.create_connection(*args, **kw)

  File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 931, in
create_connection

raise errors.KerberosError(message=unicode(krberr))

ipalib.errors.KerberosError: Major (851968): Unspecified GSS failure.
Minor code may provide more information, Minor (2529639066): Cannot find
KDC for realm "UK.INTERNAL.MYDOMAIN.COM"






Installation log:


2017-03-02T15:38:32Z DEBUG /usr/sbin/ipa-client-install was invoked with
options: {'domain': 'freeipa.uk.internal.mydomain.com', 'force': False,
'krb5_offline_passwords': True, 'ip_addresses': [], 'configure_firefox':
False, 'primary': False, 'realm_name': 'UK.INTERNAL.MYDOMAIN.COM',
'force_ntpd': True, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp':
True, 'on_master': False, 'no_nisdomain': False, 'nisdomain': None,
'ca_cert_file': None, 'principal': 'admin', 'keytab': None, 'hostname':
None, 'request_cert': False, 'trust_sshfp': False, 'no_ac': False,
'unattended': True, 'all_ip_addresses': False, 'location': None, 'sssd':
True, 'ntp_servers': None, 'kinit_attempts': 5, 'dns_updates': False,
'conf_sudo': True, 'conf_ssh': True, 'force_join': True, 'firefox_dir':
None, 'server': None, 'prompt_password': False, 'permit': False, 'debug':
False, 'preserve_sssd': False, 'mkhomedir': True, 'uninstall': False}

2017-03-02T15:38:32Z DEBUG missing options might be asked for interactively
later

2017-03-02T15:38:32Z DEBUG IPA version 4.4.0-14.el7.centos.4

2017-03-02T15:38:32Z DEBUG [IPA Discovery]

2017-03-02T15:38:32Z DEBUG Starting IPA discovery with domain=
freeipa.uk.internal.mydomain.com, servers=None, hostname=portalwaf2.uk

2017-03-02T15:38:32Z DEBUG Search for LDAP SRV record in
freeipa.uk.internal.mydomain.com

2017-03-02T15:38:32Z DEBUG Search DNS for SRV record of _ldap._
tcp.freeipa.uk.internal.mydomain.com

2017-03-02T15:38:32Z DEBUG DNS record found: 60 0 389
ipa1.uk.internal.mydomain.com.

2017-03-02T15:38:32Z DEBUG DNS record found: 40 0 389

Re: [Freeipa-users] cannot connect to ldaps during replica install, port 636 not listening

[Martin Basti]

On 02.03.2017 16:55, Chris Herdt wrote:
>
>
> On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti  > wrote:
>
>
>
> On 02.03.2017 01:07, Chris Herdt wrote:
>> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3
>> from a FreeIPA 3.0.0 master on CentOS 6.8 following the steps at
>> 
>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html
>> 
>> 
>>
>> At this step:
>> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir
>> /var/lib/ipa/replica-info-replicaname.example.com.gpg
>>
>> I get the error:
>> ERROR cannot connect to 'ldaps://master.example.com
>> '
>>
>> I ran ipa-replica-conncheck and found that port 636 is not
>> accessible:
>> Port check failed! Inaccessible port(s): 636 (TCP)
>>
>> The port is not blocked. I'm wondering where in the configuration
>> for FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or
>> if there is a way I can specify to use port 389 for setting up
>> the replica.
>>
>> Thanks!
>>
>> -- 
>> Chris Herdt
>> Systems Administrator
>>
>>
>
> Hello,
> this is known issue only in FreeIPA 4.4.x, this will be fixed  in
> next minor update which should be released soon to RHEL7.3 (I
> don't know how fast it will be in Centos)
>
> so you can wait, or enable it manually (not nice)
>
> sorry for troubles
> Martin
>
>
>
> Thanks for the reply! Before attempting this in my production
> environment, I had set up a similar configuration in a test
> environment (FreeIPA 3.0.0 master on CentOS 6.8, FreeIPA 4.4.0 replica
> on CentOS 7.3) and the ipa-replica-install went fine. I assumed this
> was an issue with my FreeIPA 3.0.0 production server.
>
> To enable the fix manually, I'm assuming I'd need to install FreeIPA
> from source on the intended replica? If I download the 4.4.3 release
> from https://pagure.io/freeipa/releases, will that be sufficient?
Sorry,
I probably misread what you wrote, I thought that port is closed on
replica, but now I see that port is closed on 3.3.0 master, so this is
something different. I'm not aware of any issue on 3.3.0 that should
cause this.

Could you check your configuration on 3.3.0 master? Is port opened on
master? Do you have any errors in /var/log/dirsrv/slapd-*/errors log on
master?

Martin



>
> Thanks again.
>
> -- 
> Chris Herdt
> Systems Administrator

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Mapping root user over kerberised NFS (with gssproxy replacing rpcsvcgssd)

[Greg]

Hi All,

Kerberised NFS works well with gssproxy for IPA users, but I'm unable to
map root user like I was with rpcsvcgssd. I understand gssproxy does not
use idmapd anymore, and the mapping has to be done in krb5 directly
(/etc/krb5.conf and/or ~/.k5login). It doesn't appear to work - any
pointers would be very welcome.

My env:

$ lsb_release -d
Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)
$ rpm -q ipa-client gssproxy
ipa-client-4.4.0-14.el7_3.4.x86_64
gssproxy-0.4.1-13.el7.x86_64
$ ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

Kerberised NFS works fine for users that exist in IPA, so I won't cover
that part of the config and focus on the root mapping.

On the "nfsserver" machine, /etc/krb5.conf is this:

includedir /var/lib/sss/pubconf/krb5.include.d/
[libdefaults]
  default_realm = DOM.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = yes
  default_ccache_name = KEYRING:persistent:%{uid}
[realms]
  DOM.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt
kdc = ipaserver.dom.com:88
master_kdc = ipaserver.dom.com:88
admin_server = ipaserver.dom.com:749
default_domain = dom.com
auth_to_local = RULE:[2:$1/$2@$0](nfs/nfsclient.dom@dom.com
)s/^.*$/root/g
auth_to_local = RULE:[2:$1/$2@$0](host/nfsclient.dom@dom.com
)s/^.*$/root/g
auto_to_local = DEFAULT
  }
[domain_realm]
  .dom.com = DOM.COM
  dom.com = DOM.COM

And the contents of "/var/lib/sss/pubconf/krb5.include.d/localauth_plugin"
are:

[plugins]
 localauth = {
  module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so
 }

I understand that does NOT mean default, rule, auth_to_local and k5login
are disabled for "localauth", they're enabled by default transparently to
my reading of krb5.conf man page (and I also confirmed k5login as working
with SSH).

Contents of /root/.k5login also on "nfsserver" machine:

host/nfsclient.dom@dom.com
nfs/nfsclient.dom@dom.com

While in possession of a ticket for either of the 2 principals above, on
"nfsclient" machine as root user, I can SSH password-less (and SSH-keyless
of course) root to root, to "nfsserver". I can no longer SSH if I don't
have either "host/..." or "nfs/..." principal on the "nfsclient". So that
confirms k5login works correctly I suppose.

Also shortly after mounting an NFS share on the "nfsclient" machine, I see
this in NFS ID translations (not sure how to read it exactly):

$ cat /proc/net/rpc/nfs4.idtoname/content
gss/krb5i user 0 host/nfsclient.dom@dom.com
gss/krb5i group 0 host/nfsclient.dom@dom.com

And yet the directory that is mounted is seen as "nobody:nobody" by root on
"nfsclient", and I can't seem to be able to convince gssproxy/nfs to map it
to root on the client.

My /etc/exports on "nfsserver":

/exports/backup
10.11.5.0/24(rw,sec=krb5:krb5i:krb5p,no_subtree_check,no_root_squash)

I also keep my "old" /etc/idmapd.conf around on "nfsserver" machine and
keep idmapd running, even though in theory this is no longer used. This is
its contents (and what used to work for me mapping root to root via
rpcsvcgssd):

[General]
Domain = dom.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
[Translation]
Method = static,sss
[Static]
host/nfsclient.dom@dom.com = root
nfs/nfsclient.dom@dom.com = root


What have I missed / what else needs to be set up where to allow gssproxy
and kerberised NFS backed by IPA to map root on NFS client?

-- 
Thanks,

Greg Kubok.
-- 
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] cannot connect to ldaps during replica install, port 636 not listening

[Chris Herdt]

On Thu, Mar 2, 2017 at 2:48 AM, Martin Basti  wrote:

>
>
> On 02.03.2017 01:07, Chris Herdt wrote:
>
> I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a
> FreeIPA 3.0.0 master on CentOS 6.8 following the steps at
> https://access.redhat.com/documentation/en-US/Red_Hat_
> Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_
> Guide/upgrading.html
>
> At this step:
> ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir
> /var/lib/ipa/replica-info-replicaname.example.com.gpg
>
> I get the error:
> ERROR cannot connect to 'ldaps://master.example.com'
>
> I ran ipa-replica-conncheck and found that port 636 is not accessible:
> Port check failed! Inaccessible port(s): 636 (TCP)
>
> The port is not blocked. I'm wondering where in the configuration for
> FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there is a
> way I can specify to use port 389 for setting up the replica.
>
> Thanks!
>
> --
> Chris Herdt
> Systems Administrator
>
>
>
> Hello,
> this is known issue only in FreeIPA 4.4.x, this will be fixed  in next
> minor update which should be released soon to RHEL7.3 (I don't know how
> fast it will be in Centos)
>
> so you can wait, or enable it manually (not nice)
>
> sorry for troubles
> Martin
>


Thanks for the reply! Before attempting this in my production environment,
I had set up a similar configuration in a test environment (FreeIPA 3.0.0
master on CentOS 6.8, FreeIPA 4.4.0 replica on CentOS 7.3) and the
ipa-replica-install went fine. I assumed this was an issue with my FreeIPA
3.0.0 production server.

To enable the fix manually, I'm assuming I'd need to install FreeIPA from
source on the intended replica? If I download the 4.4.3 release from
https://pagure.io/freeipa/releases, will that be sufficient?

Thanks again.

-- 
Chris Herdt
Systems Administrator
-- 
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] Switch sudoers to IPA

[Jakub Hrozek]

On Thu, Mar 02, 2017 at 07:09:41PM +0530, deepak dimri wrote:
> Hi List,
> 
> I have sudo and normal users accessing linux systems using their private
> key without IPA. I have IPA fully functioning and now i want to switch the
> users from local file login to IPA.
> 
> Any new user i create in IPA can SSH into ipa client jump boxes fine. I
> want to know how i can migrate existing local sudoers users to IPA.  This
> is what i have done to achieve this:
> 
> 1-  Created a new user in IPA with the same name as i have in Jumpbox.
> 2 - Added the public key of that user in IPA.
> 3-  Added the user to jumpbox_usergroup as my sshd.conf forces the users of
> this group to authenticate against the pam/sssd
> 
> Now when i try to ssh into jumpbox using as i was doing before i still logs
> into the jumpbox via unix pam and not IPA.  What should i be doing so that
> the "existing" local unix users can login via IPA?

But do you need to keep the local users around? Why not create the IPA
user with the same UID as the local user and remove the local user?

Typically, if there is a user both in the local files and a remote
source, the system (as configured in nsswitch.conf) would first return
the local user and the PAM stack then only authenticates this user using
pam_unix.so

-- 
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] Local users migration into IPA

[deepak dimri]

Hello All,

I have whole bunch of linux users that i want to migrate to IPA. All these
users uses their ssh private keys (no passwords) to login into the linux
system. What steps i should be following to migrate existing linux users
seamlessly to IPA server? since the passwords are not involved i am
thinking it would be rather simple exercise.

This is what i was thinking :

1- Create linux user with same name in IPA
2- Add public cert for each user in IPA
3- I am assuming there is no configuration change in need on ipa clients as
i can login to IPA server fine with new user if thats not the case then
what configuration changes i should be doing on ipaclient?

Do i need to delete local entry of the users from the ipa client for
authentication to go through IPA and not locally? if so then can i anyway
avoid this and rather force the user to authenticate against IPA and not
locally w/out deleting the local entries?

Would truly appreciate if you can provide some direction to this use case.

Thanks,
Deepak
-- 
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 hanging

[Terry John]

>> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The 
>> problem manifests itself as no authentication, and no DNS.
>> It seems Kerberos just stops responding to requests and requests just
>> get queued up # netstat -tuna | grep SYN_RECV Active Internet
>> connections (servers and established)
>> Proto Recv-Q Send-Q Local Address   Foreign Address 
>> State
>> tcp0 0   :88   > IP>:55440 SYN_RECV
>> tcp0 0   :88   > IP>:40076SYN_RECV
>>
>> Looking at /var/log/krb5kdc.log
>> The normal activity of AS_REQ and TGS_REC messages just stops. No error 
>> messages. Just  no new messages.

>The problem isn't in Kerberos or DNS, ns-slapd is hanging. See this, 
>http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#debugging-hangs
>rob

Thanks for that. I've taken a look at the stacktrace of out ns-slapd for our 
realm. But the stacktrace doesn't give very much. Just lots of "no debugging 
symbols found" and "No symbol table info available" it seems.
In the list of threads there are lots of calls to functions but again "No 
symbol table info available." Nothing jumps out.
Similarly in the access log, while there is a lot of activity nothing is 
obviously wrong.

I didn't change the log buffering for very long, due to the predicted 
performance issues and did not catch it when it was faulty.

For some reason, apart from once last evening the issue seems to have gone away 
now..

Terry




Cox Automotive group of companies within the UK comprises: Cox Automotive UK 
Limited (registered number: 03183918), Manheim Limited (registered number: 
00448761), Cox Automotive Retail Solutions Limited (registered number: 
02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time 
Communications Limited (registered number: 04277845). Each of these companies 
is registered in England and Wales with the registered office address of 
Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group 
of companies within the UK operates under various brand/trading names including 
Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime 
and Closeit.

V:0CF72C13B2AD



-- 
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 4.4 CA Replications

[Martin Basti]

Did you run ipa-ca-install on server2 ?


On 02.03.2017 15:20, Matt Wells wrote:
> Thank you for the response Martin.  Server1 had no flags upon install
> however CA, DNS were selected during the installation.  Server2 was
> joined and then the 'ipa-replica-install --skip-conn-check' used to
> join it.  Manual tests of the ports showed all was good but not in the
> installation so I had to use the '--skip-conn-check'.
> Server1 - 
>   Maximum username length: 32
>   Home directory base: /home
>   Default shell: /bin/sh
>   Default users group: ipausers
>   Default e-mail domain: lci.devdomain.com 
>   Search time limit: 2
>   Search size limit: 100
>   User search fields: uid,givenname,sn,telephonenumber,ou,title
>   Group search fields: cn,description
>   Enable migration mode: FALSE
>   Certificate Subject base: O=LCI.DEVDOMAIN.COM 
>   Password Expiration Notification (days): 4
>   Password plugin features: AllowNThash
>   SELinux user map order:
> guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
>   Default SELinux user: unconfined_u:s0-s0:c0.c1023
>   Default PAC types: nfs:NONE, MS-PAC
>   IPA masters: server1.lci.devdomain.com
> , server2.lci.devdomain.com
> 
>   IPA CA servers: server1.lci.devdomain.com
> 
>   IPA NTP servers: server1.lci.devdomain.com
> , server2.lci.devdomain.com
> 
>   IPA CA renewal master: server1.lci.devdomain.com
> 
>
>
>
> On Thu, Mar 2, 2017 at 12:39 AM Martin Basti  > wrote:
>
>
>
> On 01.03.2017 22:00, Matt Wells wrote:
>> I have two new IPA 4.4 servers on CentOS7 installed in a lab.  I
>> built the first, joined the second and promoted it to be a
>> master.  Thus far all went well.  
>>
>> I then ran the ipa-ca-install and when I log back in I see that
>> it has "domain,CA" attached to it.  However when I hit the main
>> IPA page it informs me I only have one server in the CA role. 
>>  Drilling down into server2 I see it does not have that role
>> assigned.  
>> I'm certain I missed an easy step but I've been unable to locate
>> it.  
>>
>> Any guidance would be greatly appreciated. 
>>
>>
>
> Hello,
>
> can you provide more info? How did you install servers (options
> used), on which server you ran ipa-ca-install ?
>
>
> Martin
>
> -- 
> *Matt Wells*
> *Lead Systems Architect*
> 
> 

-- 
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 4.4 CA Replications

[Matt Wells]

Thank you for the response Martin.  Server1 had no flags upon install
however CA, DNS were selected during the installation.  Server2 was joined
and then the 'ipa-replica-install --skip-conn-check' used to join it.
Manual tests of the ports showed all was good but not in the installation
so I had to use the '--skip-conn-check'.
Server1 -
  Maximum username length: 32
  Home directory base: /home
  Default shell: /bin/sh
  Default users group: ipausers
  Default e-mail domain: lci.devdomain.com
  Search time limit: 2
  Search size limit: 100
  User search fields: uid,givenname,sn,telephonenumber,ou,title
  Group search fields: cn,description
  Enable migration mode: FALSE
  Certificate Subject base: O=LCI.DEVDOMAIN.COM
  Password Expiration Notification (days): 4
  Password plugin features: AllowNThash
  SELinux user map order:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
  Default SELinux user: unconfined_u:s0-s0:c0.c1023
  Default PAC types: nfs:NONE, MS-PAC
  IPA masters: server1.lci.devdomain.com, server2.lci.devdomain.com
  IPA CA servers: server1.lci.devdomain.com
  IPA NTP servers: server1.lci.devdomain.com, server2.lci.devdomain.com
  IPA CA renewal master: server1.lci.devdomain.com



On Thu, Mar 2, 2017 at 12:39 AM Martin Basti  wrote:

>
>
> On 01.03.2017 22:00, Matt Wells wrote:
>
> I have two new IPA 4.4 servers on CentOS7 installed in a lab.  I built the
> first, joined the second and promoted it to be a master.  Thus far all went
> well.
>
> I then ran the ipa-ca-install and when I log back in I see that it has
> "domain,CA" attached to it.  However when I hit the main IPA page it
> informs me I only have one server in the CA role.
>  Drilling down into server2 I see it does not have that role assigned.
> I'm certain I missed an easy step but I've been unable to locate it.
>
> Any guidance would be greatly appreciated.
>
>
>
> Hello,
>
> can you provide more info? How did you install servers (options used), on
> which server you ran ipa-ca-install ?
>
>
> Martin
>
-- 
*Matt Wells*
*Lead Systems Architect*


-- 
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 mount NFS, but user only gets the permission question marks

[Brendan Kearney]

On 03/02/2017 08:43 AM, Kees Bakker wrote:

On 02-03-17 13:34, Brendan Kearney wrote:

On 03/02/2017 05:40 AM, Kees Bakker wrote:

On 24-02-17 14:38, Brendan Kearney wrote:

On 02/24/2017 03:33 AM, Kees Bakker wrote:

On 23-02-17 15:39, Brendan Kearney wrote:

On 02/23/2017 09:11 AM, Kees Bakker wrote:

On 23-02-17 13:51, Brendan Kearney wrote:

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So, 
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

The mount command is simple.
$ sudo mount -v -t nfs srv1.example.com:/home /nfshome
mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
mount.nfs: trying text-based options 
'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo mount |grep nfs
srv1.example.com:/home on /nfshome type nfs4 
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d?   ? ??   ?? nfshome


[...]

Continuing story...

I've tried various things in the meantime. I've set up two test environments 
with virtual
machines (virtualbox).
* with Fedora 25; this works.
* with Ubuntu 16.04; I'm getting the same problem (permission denied and 
question marks).

I also looked at the verbose output of rpc.gssd, it gives

ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS 
failure.  Minor code may provide more information) - Can't find client 
principal keesb@REALM in cache collection

does the actual error message say @REALM, or did you substitute that to obscure 
sensitive info?  if it does actually say @REALM, then you are missing a config 
directive somewhere, that specifies the kerberos realm.

Be assured that I'm using the real thing.


getting credentials for client with uid 60001 for server srv1.example.com
getting credentials for client with uid 60001 for server srv1.example.com
WARNING: Failed to create krb5 context for user with uid 60001 for server 
srv1.example.com

So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not 
for another
user.

Log when root is listing the NFS directory
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall 
(/run/rpc_pipefs/nfs/clnt14)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 
service=* enctypes=18,17,16,23,3,1,2 '
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall 
(/run/rpc_pipefs/nfs/clnt14)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 
'srv1.example.com'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 
'clnt1.example.com'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
root/clnt1.example.com@REALM while getting keytab entry for 
'root/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
nfs/clnt1.example.com@REALM while getting keytab entry for 
'nfs/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 
'host/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 
'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: INFO: Credentials in CC 
'FILE:/tmp/krb5ccmachine_REALM' are good until 1488535153
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: using FILE:/tmp/krb5ccmachine_REALM as 
credentials cache for machine creds
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: using environment variable to select krb5 
ccache FILE:/tmp/krb5ccmachine_REALM
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: creating context using fsuid 0 (save_uid 
0)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: creating tcp client for server 
srv1.example.com
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: DEBUG: port already set to 2049
Mar  2 14:23:52 

Re: [Freeipa-users] Can mount NFS, but user only gets the permission question marks

[Kees Bakker]

On 02-03-17 13:34, Brendan Kearney wrote:
> On 03/02/2017 05:40 AM, Kees Bakker wrote:
>> On 24-02-17 14:38, Brendan Kearney wrote:
>>> On 02/24/2017 03:33 AM, Kees Bakker wrote:
 On 23-02-17 15:39, Brendan Kearney wrote:
> On 02/23/2017 09:11 AM, Kees Bakker wrote:
>> On 23-02-17 13:51, Brendan Kearney wrote:
>>> On 02/23/2017 07:32 AM, Kees Bakker wrote:
 On 22-02-17 17:33, Brendan Kearney wrote:
> On 02/22/2017 10:26 AM, Kees Bakker wrote:
>> On 22-02-17 14:05, Brendan Kearney wrote:
>>> On 02/22/2017 05:23 AM, Kees Bakker wrote:
 On 21-02-17 19:49, Brendan Kearney wrote:
> On 02/21/2017 10:57 AM, Kees Bakker wrote:
>> Hey,
>>
>> Maybe one of the NFS users on this list could give me a hint what
>> could be wrong. I'm not sure if it has any relation with 
>> FreeIPA/Kerberos.
>>
>> I've set up an NFS server and I can mount the NFS directory on 
>> my client. So, I'm
>> guessing that setting up Kerberos principal was done correctly.
>>
>> However, only root can actually access the mounted contents. Any 
>> other user
>> only sees question marks as shown below.
>>
>> The mount command is simple.
>> $ sudo mount -v -t nfs srv1.example.com:/home /nfshome
>> mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
>> mount.nfs: trying text-based options 
>> 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'
>>
>> On the server side /etc/exports looks like this.
>> /home*(rw,sync,sec=krb5i,no_subtree_check)
>>
>> $ sudo mount |grep nfs
>> srv1.example.com:/home on /nfshome type nfs4 
>> (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)
>>
>> $ sudo ls -ld /nfshome
>> drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
>> $ sudo ls -l /nfshome
>> total 0
>> drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb
>>
>> $ ls -l /nfshome
>> ls: cannot access '/nfshome': Permission denied
>> $ ls -l / | grep nfshome
>> ls: cannot access '/nfshome': Permission denied
>> d?   ? ??   ?? nfshome
>>
>> [...]
>>
>> Continuing story...
>>
>> I've tried various things in the meantime. I've set up two test environments 
>> with virtual
>> machines (virtualbox).
>> * with Fedora 25; this works.
>> * with Ubuntu 16.04; I'm getting the same problem (permission denied and 
>> question marks).
>>
>> I also looked at the verbose output of rpc.gssd, it gives
>>
>> ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS 
>> failure.  Minor code may provide more information) - Can't find client 
>> principal keesb@REALM in cache collection
> does the actual error message say @REALM, or did you substitute that to 
> obscure sensitive info?  if it does actually say @REALM, then you are missing 
> a config directive somewhere, that specifies the kerberos realm.

Be assured that I'm using the real thing.

>> getting credentials for client with uid 60001 for server srv1.example.com
>> getting credentials for client with uid 60001 for server srv1.example.com
>> WARNING: Failed to create krb5 context for user with uid 60001 for server 
>> srv1.example.com

So rpc.gssd is trying to create a krb5 context. It succeeds for uid=0 but not 
for another
user.

Log when root is listing the NFS directory
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handling gssd upcall 
(/run/rpc_pipefs/nfs/clnt14)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handle_gssd_upcall: 'mech=krb5 uid=0 
service=* enctypes=18,17,16,23,3,1,2 '
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: handling krb5 upcall 
(/run/rpc_pipefs/nfs/clnt14)
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: process_krb5_upcall: service is '*'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'srv1.example.com' is 
'srv1.example.com'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Full hostname for 'clnt1.example.com' is 
'clnt1.example.com'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
CLNT1.REALM$@REALM while getting keytab entry for 'CLNT1.REALM$@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
root/clnt1.example.com@REALM while getting keytab entry for 
'root/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: No key table entry found for 
nfs/clnt1.example.com@REALM while getting keytab entry for 
'nfs/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: Success getting keytab entry for 
'host/clnt1.example.com@REALM'
Mar  2 14:23:52 clnt1 rpc.gssd[3612]: INFO: 

[Freeipa-users] Switch sudoers to IPA

[deepak dimri]

Hi List,

I have sudo and normal users accessing linux systems using their private
key without IPA. I have IPA fully functioning and now i want to switch the
users from local file login to IPA.

Any new user i create in IPA can SSH into ipa client jump boxes fine. I
want to know how i can migrate existing local sudoers users to IPA.  This
is what i have done to achieve this:

1-  Created a new user in IPA with the same name as i have in Jumpbox.
2 - Added the public key of that user in IPA.
3-  Added the user to jumpbox_usergroup as my sshd.conf forces the users of
this group to authenticate against the pam/sssd

Now when i try to ssh into jumpbox using as i was doing before i still logs
into the jumpbox via unix pam and not IPA.  What should i be doing so that
the "existing" local unix users can login via IPA?

I am still playing with configuration to make it work but thought of asking
this to you all to see if i can get a solution faster.

Many Thanks,
Deepak
-- 
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] freeipa3.0.0 can't renew certificate

[hao]

now I execute getcert list，all certificate status MONITORING,but there was an 
error 
ca-error: Internal error: no response to 
"http://ipaserver.xxx.io:9180/ca/ee/ca/profileSubmit?profileId=caServerCert_num=2=true=true;






At 2017-03-02 11:34:10, "hao"  wrote:

Hi:


I have finished reading http://www.freeipa.org/page/IPA_2x_Certificate_Renewal  
, before execute,I stop tracking all cert in `getcert list`
Now, only "issuer: CN=IPA RA,O=XXX.IO " certificate expires at 2018-02-28 
08:14:38 UTC,other certificate still expires at 2017-02-15 06:10:36 UTC，
I execute 
"for nickname in "auditSigningCert cert-pki-ca" "ocspSigningCert cert-pki-ca" 
"subsystemCert cert-pki-ca" "Server-Cert cert-pki-ca"
 do
 /usr/bin/getcert start-tracking -d /var/lib/pki-ca/alias -n "${nickname}" 
-c dogtag-ipa-renew-agent -P xx
 done"
and all command in "http://www.freeipa.org/page/IPA_2x_Certificate_Renewal;  
but still no effect
I've tried “http://www.freeipa.org/page/Certmonger” 
“http://www.freeipa.org/page/Howto/CA_Certificate_Renewal”  
“http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master” before 
that，I'm not sure if there will be an error step


Please help me 


Thank you




 




【网易自营|30天无忧退货】差旅打包必备“MUJI制造商梭织布多层收纳包”，让出行更完美>>-- 
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] documentation or example of using S42U for NFS

[Greg]

I've been at this as well for a while now, and managed to make it work for
my NFS needs (automounting user homes with password-less logons).

Whether and how this would apply to cron or other services, I don't know
yet, but presumably would/should work in a similar manner.

My env:

$ lsb_release -d
Description: Red Hat Enterprise Linux Server release 7.3 (Maipo)
$ rpm -q ipa-server
ipa-server-4.4.0-14.el7_3.4.x86_64
$ ipa --version
VERSION: 4.4.0, API_VERSION: 2.213

This is what worked for me in the end:

1. Create "nfs/nfsserver.dom@dom.com" service, and add to NFS server's
/etc/krb5.keytab.

2. Create IPA "servicedelegation" rule/targets, so that they look like so:

$ ipa servicedelegationrule-show ipa-nfs-delegation
  Delegation name: ipa-nfs-delegation
  Allowed Target: ipa-nfs-delegation-targets
  Member principals: *host*/*nfsclient*.dom@dom.com

$ ipa servicedelegationtarget-show ipa-nfs-delegation-targets
  Delegation name: ipa-nfs-delegation-targets
  Member principals: *nfs*/*nfsserver*.dom@dom.com

Only niggle here is IPA CLI didn't let me add "host/..." principal to the
rule, or perhaps there's a default LDAP ACI of some sort and it requires a
privilege/permission to be granted. The "ipa
servicedelegationrule-add-member ..." command simply says "no such entry"
for "host/..." type principals. Maybe IPA folks can comment.

I force added it to the delegation rule via LDAP instead using this ldif:

dn: cn=ipa-nfs-delegation,cn=s4u2proxy,cn=etc,dc=dom,dc=com
changetype: modify
add: memberPrincipal
memberPrincipal: host/nfsclient.dom@dom.com

The "nfs/..." principal can be added using CLI
"ipa servicedelegationtarget-add-member ..." just fine.

3. Allow the "nfsclient" host to impersonate users:

$ ipa host-mod nfsclient.dom.com --ok-to-auth-as-delegate=true

4. On the "nfsclient" machine, add "impersonate = true" line in the
"[service/nfs-client]" section of /etc/gssproxy/gssproxy.conf.

5. Restart nfs/gssproxy/rpc services on client and server (it's probably
just gssproxy on the client that needs a kick, but just to be sure). I was
also religiously doing "sss_cache -E" for good measure, unmounting anything
that got mounted, and clearing /var/lib/gssproxy/clients of all caches, to
start as cleanly before each attempt at user logon. Obv make sure the user
does not have an existing/valid ticket in their own cache ("kdestroy -A" as
the user), otherwise it'll just mount successfully without delegation.

I think that's it, I've messed about with the config for a long time and in
many places, so there's a small chance there's something else that I did
and don't remember. Gssproxy config on "nfsserver" is vanilla, as are my
sssd.confs and krb5.confs on both machines, can't think of much else that I
might've changed for now.

So my IPA automount config now mounts users' home dirs on the "nfsclient",
without any tickets or keytabs from users.

There's also a "krb5_principal" option available in gssproxy.conf - I tried
to set that to "nfs/nfscli...@dom.com" in "[service/nfs-client]" section on
the "nfsclient" machine, to try and force gssproxy to use that principal
instead of "host/...", but it didn't seem to work, gssproxy defaults to
"host/...". Possibly mis-understanding what this option is for, and
possibly "host/..." is the safer/standard option? I'm assuming it's default
for a reason, or maybe just operational convenience (not having to pollute
/etc/krb5.keytabs with more principals than necessary).

Hope this helps.

--
Thanks,

Greg Kubok.

On 1 March 2017 at 22:47, Orion Poplawski  wrote:

> If you ever get this into a repository, I'd love to see it.  Thanks.
>
> On 01/17/2017 07:44 PM, Charles Hedrick wrote:
> > Instructions like that are several places. But NFS is different, and I
> believe the configuration would be different from other services.
> >
> > I’ve given up on this approach, and have written my own utilities. I’ve
> actually got three. The first two assume that users who want to do cron
> jobs on a machine register a keytab for that machine on a secure system. I
> don’t want to put the actual keytab on the machine where the user is
> running, because if someone can become root, they can take the keytab and
> use it anywhere. (I’m in a computer science dept with systems run by
> faculty and grad students; also systems in public labs.)
> >
> > So instead, I allow users to register that they want to do cron on a
> specific machine by putting a keytab on a secure server, associated with
> their username and the hostname. I expect to write a web app to set that up.
> >
> > Credserv runs on the machine with the keytabs. It accepts a request from
> a server, authenticated using the host’s host key (i.e. /etc/krb5.keytab),
> with a username in the request. If the user has registered a keytab for
> that host, credserv returns a credential, locked to that IP address, with
> forwarding off.
> >
> > Kgetcred is the client side. It runs setuid root (so it can 

Re: [Freeipa-users] Kerberos hanging

[Terry John]

Thanks for that.

I have an issue with NTP but I have got around that and spent many a happy hour 
updating the times on my clients. The errors were in /var/log/krb5kdc.log as 
"clock skew too great". It's only when I got rid of them, and there were many, 
could I clearly see the normal operation

Terry John

>Check time an date on all involved servers/workstations - if the difference is 
>more than 300 seconds , Kerberos might not work correctly. Apply the same time 
>to all involved >servers/workstations.

>Gerald

>> I have a problem using freeipa version 3.0.0-50 on CentOS release 6.8. The 
>> problem manifests itself as no authentication, and no DNS.
>> It seems Kerberos just stops responding to requests and requests just
>> get queued up # netstat -tuna | grep SYN_RECV Active Internet
>> connections (servers and established)
>> Proto Recv-Q Send-Q Local Address   Foreign Address 
>> State
>> tcp0 0   :88   > IP>:55440 SYN_RECV
>> tcp0 0   :88   > IP>:40076SYN_RECV
>> tcp0 0   :88   > IP>:41525SYN_RECV
>> tcp0 0   :88   > IP>:53958 SYN_RECV
>> tcp0 0   :88   > IP>:54240 SYN_RECV
>> Looking at /var/log/krb5kdc.log
>> The normal activity of AS_REQ and TGS_REC messages just stops. No error 
>> messages. Just  no new messages.
>> In /var/log/messages the named server reports messages like Mar  1
>> 00:00:23 freeipa named[18989]: LDAP error: Can't contact LDAP server
>> Mar  1 00:00:23 freeipa named[18989]: connection to the LDAP server
>> was lost Mar  1 00:00:23 freeipa named[18989]: bind to LDAP server
>> failed: Can't contact LDAP server
>> The command "kinit" is totally unresponsive and will time out if you wait 
>> long enough.
>> If I try to restart ipa with "service ipa restart", it hangs on the first 
>> stage, trying to stop DIRSRV.
>> I have to do a "ps ax" and look for this line.
>> 2758 ?Sl 2:13 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-MY-REALM 
>> -i /var/run/dirsrv/slapd-MY-REALM.pid -w 
>> /var/run/dirsrv/slapd-MY-REALM.startpid
>> Then I have to a "kill -9" on the pid
>> Then I can do "service ipa restart"
>> After that it works ok for a while. "A while" may be a few minutes or 
>> several hours.
>> The filesystem is only 58% used and "free" shows no swap in use so there 
>> seems to be plenty of RAM available.
>> "top" shows CPU(s) 96% idle with "dirsirv" typically using about 3%CPU  at 
>> most


Cox Automotive group of companies within the UK comprises: Cox Automotive UK 
Limited (registered number: 03183918), Manheim Limited (registered number: 
00448761), Cox Automotive Retail Solutions Limited (registered number: 
02838588), Motors.co.uk Limited (registered number: 05975777), and Real Time 
Communications Limited (registered number: 04277845). Each of these companies 
is registered in England and Wales with the registered office address of 
Central House, Leeds Road, Rothwell, Leeds LS26 0JE. The Cox Automotive group 
of companies within the UK operates under various brand/trading names including 
Cox Automotive UK, Manheim Inspection Services, Manheim Auctions, Modix, Xtime 
and Closeit.

V:0CF72C13B2AD



-- 
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 mount NFS, but user only gets the permission question marks

[Brendan Kearney]

On 03/02/2017 05:40 AM, Kees Bakker wrote:

On 24-02-17 14:38, Brendan Kearney wrote:

On 02/24/2017 03:33 AM, Kees Bakker wrote:

On 23-02-17 15:39, Brendan Kearney wrote:

On 02/23/2017 09:11 AM, Kees Bakker wrote:

On 23-02-17 13:51, Brendan Kearney wrote:

On 02/23/2017 07:32 AM, Kees Bakker wrote:

On 22-02-17 17:33, Brendan Kearney wrote:

On 02/22/2017 10:26 AM, Kees Bakker wrote:

On 22-02-17 14:05, Brendan Kearney wrote:

On 02/22/2017 05:23 AM, Kees Bakker wrote:

On 21-02-17 19:49, Brendan Kearney wrote:

On 02/21/2017 10:57 AM, Kees Bakker wrote:

Hey,

Maybe one of the NFS users on this list could give me a hint what
could be wrong. I'm not sure if it has any relation with FreeIPA/Kerberos.

I've set up an NFS server and I can mount the NFS directory on my client. So, 
I'm
guessing that setting up Kerberos principal was done correctly.

However, only root can actually access the mounted contents. Any other user
only sees question marks as shown below.

The mount command is simple.
$ sudo mount -v -t nfs srv1.example.com:/home /nfshome
mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
mount.nfs: trying text-based options 
'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

On the server side /etc/exports looks like this.
/home*(rw,sync,sec=krb5i,no_subtree_check)

$ sudo mount |grep nfs
srv1.example.com:/home on /nfshome type nfs4 
(rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

$ sudo ls -ld /nfshome
drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
$ sudo ls -l /nfshome
total 0
drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

$ ls -l /nfshome
ls: cannot access '/nfshome': Permission denied
$ ls -l / | grep nfshome
ls: cannot access '/nfshome': Permission denied
d?   ? ??   ?? nfshome


[...]

Continuing story...

I've tried various things in the meantime. I've set up two test environments 
with virtual
machines (virtualbox).
* with Fedora 25; this works.
* with Ubuntu 16.04; I'm getting the same problem (permission denied and 
question marks).

I also looked at the verbose output of rpc.gssd, it gives

ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS 
failure.  Minor code may provide more information) - Can't find client 
principal keesb@REALM in cache collection
does the actual error message say @REALM, or did you substitute that to 
obscure sensitive info?  if it does actually say @REALM, then you are 
missing a config directive somewhere, that specifies the kerberos realm.

getting credentials for client with uid 60001 for server srv1.example.com
getting credentials for client with uid 60001 for server srv1.example.com
WARNING: Failed to create krb5 context for user with uid 60001 for server 
srv1.example.com

But the user really did get a TGT.

$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
02-03-17 10:25:25  03-03-17 10:25:22  krbtgt/example@example.com

So, still no solution for Ubuntu + freeipa + nfs.

BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. 
However,
there is only any output when root (uid 0) does a NFS directory lookup. When a 
regular
user tries to stat the NFS directory it does not even get to the point where id 
mapping is
done.



--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project

[Freeipa-users] xrdp and free ipa

[Craig Warner]

Has anyone on the list any experience or knowledge in setting up xrdp using 
freeipa as authentication on Centos 7?

I have little to limited experience in both.

-- 
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 mount NFS, but user only gets the permission question marks

[Kees Bakker]

On 24-02-17 14:38, Brendan Kearney wrote:
> On 02/24/2017 03:33 AM, Kees Bakker wrote:
>> On 23-02-17 15:39, Brendan Kearney wrote:
>>> On 02/23/2017 09:11 AM, Kees Bakker wrote:
 On 23-02-17 13:51, Brendan Kearney wrote:
> On 02/23/2017 07:32 AM, Kees Bakker wrote:
>> On 22-02-17 17:33, Brendan Kearney wrote:
>>> On 02/22/2017 10:26 AM, Kees Bakker wrote:
 On 22-02-17 14:05, Brendan Kearney wrote:
> On 02/22/2017 05:23 AM, Kees Bakker wrote:
>> On 21-02-17 19:49, Brendan Kearney wrote:
>>> On 02/21/2017 10:57 AM, Kees Bakker wrote:
 Hey,

 Maybe one of the NFS users on this list could give me a hint what
 could be wrong. I'm not sure if it has any relation with 
 FreeIPA/Kerberos.

 I've set up an NFS server and I can mount the NFS directory on my 
 client. So, I'm
 guessing that setting up Kerberos principal was done correctly.

 However, only root can actually access the mounted contents. Any 
 other user
 only sees question marks as shown below.

 The mount command is simple.
 $ sudo mount -v -t nfs srv1.example.com:/home /nfshome
 mount.nfs: timeout set for Tue Feb 21 16:36:39 2017
 mount.nfs: trying text-based options 
 'vers=4,addr=172.16.16.45,clientaddr=172.16.16.30'

 On the server side /etc/exports looks like this.
 /home*(rw,sync,sec=krb5i,no_subtree_check)

 $ sudo mount |grep nfs
 srv1.example.com:/home on /nfshome type nfs4 
 (rw,relatime,vers=4.0,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=krb5i,clientaddr=172.16.16.30,local_lock=none,addr=172.16.16.45)

 $ sudo ls -ld /nfshome
 drwxr-xr-x 1 root root 72 feb 21 04:22 /nfshome
 $ sudo ls -l /nfshome
 total 0
 drwxr-xr-x 1 keesb  keesb  116 jan 27 12:56 keesb

 $ ls -l /nfshome
 ls: cannot access '/nfshome': Permission denied
 $ ls -l / | grep nfshome
 ls: cannot access '/nfshome': Permission denied
 d?   ? ??   ?? nfshome

>>>
[...]

Continuing story...

I've tried various things in the meantime. I've set up two test environments 
with virtual
machines (virtualbox).
* with Fedora 25; this works.
* with Ubuntu 16.04; I'm getting the same problem (permission denied and 
question marks).

I also looked at the verbose output of rpc.gssd, it gives

ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS 
failure.  Minor code may provide more information) - Can't find client 
principal keesb@REALM in cache collection
getting credentials for client with uid 60001 for server srv1.example.com
getting credentials for client with uid 60001 for server srv1.example.com
WARNING: Failed to create krb5 context for user with uid 60001 for server 
srv1.example.com

But the user really did get a TGT.

$ klist
Ticket cache: KEYRING:persistent:60001:60001
Default principal: ke...@example.com

Valid starting ExpiresService principal
02-03-17 10:25:25  03-03-17 10:25:22  krbtgt/example@example.com

So, still no solution for Ubuntu + freeipa + nfs.

BTW. I've enabled verbosity in /etc/idmapd.conf. The logging tells me it is OK. 
However,
there is only any output when root (uid 0) does a NFS directory lookup. When a 
regular
user tries to stat the NFS directory it does not even get to the point where id 
mapping is
done.
-- 
Kees

-- 
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] cannot connect to ldaps during replica install, port 636 not listening

[Martin Basti]

On 02.03.2017 01:07, Chris Herdt wrote:
I am attempting to set up a FreeIPA 4.4.0 replica on CentOS 7.3 from a 
FreeIPA 3.0.0 master on CentOS 6.8 following the steps at 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html


At this step:
ipa-replica-install --ip-address=xxx.xxx.xxx.xxx --mkhomedir 
/var/lib/ipa/replica-info-replicaname.example.com.gpg


I get the error:
ERROR cannot connect to 'ldaps://master.example.com 
'


I ran ipa-replica-conncheck and found that port 636 is not accessible:
Port check failed! Inaccessible port(s): 636 (TCP)

The port is not blocked. I'm wondering where in the configuration for 
FreeIPA 3.0.0 I should check the LDAPS (mis)configuration, or if there 
is a way I can specify to use port 389 for setting up the replica.


Thanks!

--
Chris Herdt
Systems Administrator




Hello,
this is known issue only in FreeIPA 4.4.x, this will be fixed  in next 
minor update which should be released soon to RHEL7.3 (I don't know how 
fast it will be in Centos)


so you can wait, or enable it manually (not nice)

sorry for troubles
Martin
-- 
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 4.4 CA Replications

[Martin Basti]

On 01.03.2017 22:00, Matt Wells wrote:
I have two new IPA 4.4 servers on CentOS7 installed in a lab.  I built 
the first, joined the second and promoted it to be a master.  Thus far 
all went well.


I then ran the ipa-ca-install and when I log back in I see that it has 
"domain,CA" attached to it.  However when I hit the main IPA page it 
informs me I only have one server in the CA role.

 Drilling down into server2 I see it does not have that role assigned.
I'm certain I missed an easy step but I've been unable to locate it.

Any guidance would be greatly appreciated.




Hello,

can you provide more info? How did you install servers (options used), 
on which server you ran ipa-ca-install ?


Martin
-- 
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] replication breaks intermittently

[Ludwig Krispenz]

On 03/01/2017 08:18 PM, pgb205 wrote:
[01/Mar/2017:18:19:48 +] agmt="cn=meTo ipa2.internal.domain" 
(ipa2:389) - Can't locate CSN 582301c3000d0077 in the changelog 
(DB rc=-30988). If replication stops, the consumer may need to be 
reinitialized.
[01/Mar/2017:18:19:48 +] NSMMReplicationPlugin - changelog program 
- agmt="cn=meToipa2.internal.domain" (ipa2:389): CSN 
582301c3000d0077 not found, we aren't as up to date, or we purged
[01/Mar/2017:18:19:48 +] NSMMReplicationPlugin - 
agmt="cn=meToipa2.internal.domain" (ipa2:389): Data required to update 
replica has been purged. The replica must be reinitialized.
[01/Mar/2017:18:19:48 +] NSMMReplicationPlugin - 
agmt="cn=meToipa2.internal.domain" (ipa2:389): Incremental update 
failed and requires administrator action
the timestamp in the csn: 582301c3 is from Nov,9, 2016. so it is very 
likely that it was trimmed from the changelog or lost during some 
reinitialization.
could you verify to which server the replicaid '0077' == 119 refers and 
if it still exists





Seeing the above in the logs after seeing problems with replication. 
The data entered on one replica isn't making it to others. There are 
no problems with connectivity between the servers and all necessary 
ports are open. Currently we are getting around this problem by 
running a script to perform force sync.


Any suggestions on the things that may be setup wrong to take a look at?






--
Red Hat GmbH, http://www.de.redhat.com/, Registered seat: Grasbrunn,
Commercial register: Amtsgericht Muenchen, HRB 153243,
Managing Directors: Charles Cachera, Michael Cunningham, Michael O'Neill, Eric 
Shander

-- 
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