[Freeipa-users] Can’t SSH with AD user to freeipa joined Centos client

[Alexandre Pitre via FreeIPA-users]

I’ve been struggling to get SSH to work with an AD user for over 3 weeks
now. I've scraped the bowels of the internet for answers, still no dice.

The issue is pretty simple in itself, I can’t SSH to a freeipa joined
Centos client 7.3 with an AD user. However, kinit with any AD users as well
as su works just fine. I’m running two 4.4.0 IPA servers.

I made sure the entire setup is resolving DNS properly, NTP(external to
freeipa) is in sync. I’m using FQDN for hostnames.

Here’s the output from journalctl -f:

Jul 27 04:37:10 centos.ipa.ad.com sshd[2633]: pam_unix(sshd:session):
session opened for user root by (uid=0)
Jul 27 04:37:35 centos.ipa.ad.com su[2652]: (to ad...@ad.com) root on pts/1
Jul 27 04:37:35 centos.ipa.ad.com su[2652]: pam_unix(su-l:session): session
opened for user ad...@ad.com by root(uid=0)
Jul 27 04:37:42 centos.ipa.ad.com su[2652]: pam_unix(su-l:session): session
closed for user ad...@ad.com
Jul 27 04:38:35 centos.ipa.ad.com sshd[2677]: pam_sss(sshd:auth):
authentication failure; logname= uid=0 euid=0 tty=ssh ruse  r=
rhost=localhost user=ad...@ad.com
Jul 27 04:38:35 centos.ipa.ad.com sshd[2677]: pam_sss(sshd:auth): received
for user ad...@ad.com: 6 (Permission denied)
Jul 27 04:38:35 centos.ipa.ad.com sshd[2674]: error: PAM: Authentication
failure for ad...@ad.com from localhost
Jul 27 04:38:38 centos.ipa.ad.com sshd[2674]: Connection closed by ::1
[preauth]



Config files:

/etc/krb5.conf

#File modified by ipa-client-install

includedir /etc/krb5.conf.d/

includedir /var/lib/sss/pubconf/krb5.include.d/

[libdefaults]
  default_realm = IP.AD.COM
  dns_lookup_realm = true
  dns_lookup_kdc = true
  rdns = false
  ticket_lifetime = 24h
  forwardable = true
  udp_preference_limit = 0
  default_ccache_name = KEYRING:persistent:%{uid}
[realms]
  IP.AD.COM = {
pkinit_anchors = FILE:/etc/ipa/ca.crt

  }

/etc/sssd/sssd.conf

[domain/ipa.ad.com]
debug_level = 9
cache_credentials = True
krb5_store_password_if_offline = True
ipa_domain = ipa.ad.com
id_provider = ipa
auth_provider = ipa
access_provider = ipa
ipa_hostname = centos.ipa.ad.com
chpass_provider = ipa
dyndns_update = True
ipa_server = _srv_, ipaserver02.ipa.ad.com
dyndns_iface = ens192
ldap_tls_cacert = /etc/ipa/ca.crt[sssd]
services = nss, sudo, pam, ssh
debug_level = 9
domains = ipa.ad.com
[nss]
homedir_substring = /home

[pam]
debug_level= 9

[sudo]

[autofs]

[ssh]
debug_level=9

[pac]

[ifp]



/etc/ssh/sshd_config

HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
SyslogFacility AUTHPRIV
PermitRootLogin yes
AuthorizedKeysFile  .ssh/authorized_keys
GSSAPICleanupCredentials no
X11Forwarding yes
UsePrivilegeSeparation sandbox  # Default for new installations.
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY
LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
Subsystem   sftp/usr/libexec/openssh/sftp-server
KerberosAuthentication no
PubkeyAuthentication yes
UsePAM yes
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
GSSAPIAuthentication yes
ChallengeResponseAuthentication yes
AuthorizedKeysCommandUser nobody


I uploaded krb5_child.log and ldap_child.log to
https://1drv.ms/f/s!AlZwwyQE2ZZ5p2b5ROa15PBkAEQD

I managed to ssh AD user login to works on both my freeipa servers. I had
to modify the following files See changes in bold.

/etc/krb5.conf

includedir /etc/krb5.conf.d/
includedir /var/lib/sss/pubconf/krb5.include.d/

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 default_realm = IPA.AD.COM
* dns_lookup_realm = true*
* dns_lookup_kdc = true*
 rdns = false
 ticket_lifetime = 24h
 forwardable = true
 udp_preference_limit = 0
 default_ccache_name = KEYRING:persistent:%{uid}

[realms]
 IPA.AD.COM = {
  kdc = ipaserver01.ipa.ad.com:88
  master_kdc = ipaserver01.ipa.ad.com:88
  admin_server = ipaserver01.ipa.ad.com:749
  default_domain = ipa.ad.com
  pkinit_anchors = FILE:/etc/ipa/ca.crt
*  auth_to_local = RULE:[1:$1@$0](^.*@AD.COM
)s/@AD.COM/@ad.com/ *
*  auth_to_local = DEFAULT*
}

[domain_realm]
 .ipa.ad.com = IPA.AD.COM
 ipa.ad.com = IPA.AD.COM
 ipaserver02.ipa.ad.com = IPA.AD.COM

[dbmodules]
  IPA.AD.COM = {
db_library = ipadb.so
  }

/etc/resolv.conf
search ipa.ad.com ad.com
nameserver 127.0.0.1
*nameserver 192.168.1.2 #Seconday IPA Server*

In /etc/named.conf, I disabled dnssec-validation(dnssec-validation no;)

Not sure those settings were at all necessary.


Adding the following line sunder the [realms] for krb5.conf on my centos
client machine did not make a difference.

 auth_to_local = RULE:[1:$1@$0](^.*@AD.COM)s/@AD.COM/@ad.com/
 auth_to_local = DEFAULT

IPv6 has been disabled in /etc/sysctl.conf

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1

If anyone has an idea wha

[Freeipa-users] Group membership expiration

[Prashant Bapat via FreeIPA-users]

Hi FreeIPA Users,

Is there a way to make the group membership have an optional expiration
date. This expiration date can be set by the admin.

Any pointers to how this can be implemented would be very helpful.

Thanks.
--Prashant
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: ipa-replica-install hanging at `[29/44]: setting up initial replication`

[John Morris via FreeIPA-users]

The `IPA_SERVER_IP` failing to correct the A-record is issue #121:

https://github.com/freeipa/freeipa-container/issues/121

That puts a neat little bow on all my questions in this email thread. 
:D  Thanks-


John

On 07/24/2017 09:26 PM, John Morris via FreeIPA-users wrote:

Never mind, I partly figured out what's wrong, once I found a clue that
this stage requires server->replica connections.

The `ipa-replica-install` process, probably during `ipa-client-install`,
adds the DNS A-record for the server, but uses the container's IP address.

The freeipa-container scripts allow for this, and if the `IPA_SERVER_IP`
environment variable is set, they will attempt to correct the A-record
with `nsupdate`.  This was silently failing (I don't know why yet).

If the A-record is set prior to running `ipa-replica-install`, the
server can find the replica, the replication can be completed, and
everything hums happily.

For folks in the future, I guess if the replica install breaks at this
particular step, it's a good clue to check connectivity from the server
to the replica.

John


On 07/24/2017 04:14 PM, John Morris via FreeIPA-users wrote:

I reinstalled both server and replica with the image you suggest.  The
same problem occurs at the same location; see the new gist:

https://gist.github.com/zultron/d7bed6d0c00ae8daef292ba4bb2c04e0

Thanks-

John

On 07/24/2017 02:47 PM, Felipe Barreto Volpone via FreeIPA-users wrote:

John,

I didn't noticed that you're using adelton's repository.
Could you try more recent image from the official docker hub (/r/freeipa
instead of /r/adelton)?
https://hub.docker.com/r/freeipa/freeipa-server/



On Mon, Jul 24, 2017 at 4:40 PM, John Morris via FreeIPA-users
mailto:freeipa-users@lists.fedorahosted.org>> wrote:

(Apologies for previously sending off-list, Felipe.)

Sure:

docker run \
--rm \
--interactive \
--restart=no \
--hostname=h01.example.com  \
--security-opt=seccomp=unconfined \
--name=ipa \
--volume=/media/freeipa:/data \
--volume=/media/state:/media/state \
--volume=/sys/fs/cgroup:/sys/fs/cgroup:ro \
--env=IPA_SERVER_IP=1.2.3.4 \
--add-host=h01.example.com:1 .2.3.4 \
--publish=80:80 \
--publish=443:443 \
--publish=53:53 \
--publish=53:53/udp \
--publish=389:389 \
--publish=636:636 \
--publish=88:88 \
--publish=88:88/udp \
--publish=464:464 \
--publish=464:464/udp \
adelton/freeipa-server:centos-7

Thanks-

John



On 07/24/2017 01:29 PM, Felipe Barreto Volpone wrote:

Hi John,

could you share the command you have run to setup the ipa
server?

On Mon, Jul 24, 2017 at 3:12 PM, John Morris via FreeIPA-users
mailto:freeipa-users@lists.fedorahosted.org>
>> wrote:

Running FreeIPA out of Docker
(`adelton/freeipa-server:centos-7`
image), `ipa-replica-install` hangs at `[29/44]: setting up
initial
replication`.  The `ipa-server-configure-first.log` (debug
output
enabled) is pasted in the below gist, plus output of
`journalctl
-xe` from within the container.


https://gist.github.com/zultron/6f9aeb47d304c7bcab93d023e36484ba




>

The options to `ipa-replica-install` look like this:

--unattended
--principal=admin
--admin-password=redacted
--server=h01.example.com 

--hostname=h11.example.com 

--realm=EXAMPLE.COM 

--domain=example.com 

--setup-ca
--setup-dns
--no-reverse
--no-forwarders
--no-host-dns
--no-ntp
--no-ui-redirect
--allow-zone-overlap
--debug
--skip-conncheck

The docker command looks like this:

docker run \
--rm \
--interactive \
--restart=no \
--hostname=h11.example.com 
 \
--security-opt=seccomp=unconfined \
--name=ipa \
--volum

[Freeipa-users] Re: Krb5.conf only sees first two kdc servers

[Michael Papet via FreeIPA-users]

>If the _srv_ is enabled then am i correct in assuming that we wouldn't even 
>need kdc= records in krb5.conf ??>I tried removing kdc= linesand was unable to 
>authenticate.
In my experience, sssd relies upon the local kerberos stack.  Maybe others have 
different experiences.
mpapet





   ___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Krb5.conf only sees first two kdc servers

[pgb205 via FreeIPA-users]

Sumit, thank you very much for this. Very helpful, but I am still not seeing 
the problem
So at first I will try with the following in krb5.confkdc=server1       <--shut 
off on the network#kdc=server2     <--shut off on the network and commented out 
in krb5.confkdc=server3      <--up and running
KRB5_TRACE=/dev/stdout kinit user@test.domain 
[12583] 1501113245.556036: Getting initial credentials for user@test.domain 
[12583] 1501113245.556244: Sending request (181 bytes) to test.domain
[12583] 1501113245.556282: Resolving hostname server1
[12583] 1501113245.557235: Sending initial UDP request to dgram 
ip_addr_server1:88
[12583] 1501113246.558328: Resolving hostname server3
[12583] 1501113246.558974: Sending initial UDP request to dgram 
ip_addr_server3:88
[12583] 1501113246.729059: Received answer (275 bytes) from dgram 
ip_addr_server3:88
[12583] 1501113246.729111: Response was from master KDC
[12583] 1501113246.729155: Received error from KDC: -1765328359/Additional 
pre-authentication required
[12583] 1501113246.729219: Processing preauth types: 136, 19, 2, 133
[12583] 1501113246.729245: Selected etype info: etype aes256-cts, salt 
"pY;=XB+5_*EjJC%S", params ""
[12583] 1501113246.729254: Received cookie: MIT
Password for user@test.domain       <--get prompted for password
Now with all three kdc uncommentedkdc=server1 <-shut off and 
uncommentedkdc=server2   <--shut off and uncommentedkdc=server3   <--up and 
running
KRB5_TRACE=/dev/stdout kinit user@test.domain 
[12536] 1501112935.251721: Getting initial credentials for user@test.domain 
[12536] 1501112935.251917: Sending request (181 bytes) to test.domain
[12536] 1501112935.251956: Resolving hostname server1
[12536] 1501112935.252875: Sending initial UDP request to dgram server1_ip:88
[12536] 1501112936.253962: Resolving hostname server2
[12536] 1501112936.255680: Retrying AS request with master KDC
[12536] 1501112936.255699: Getting initial credentials for user@test.domain
[12536] 1501112936.255763: Sending request (181 bytes) to test.domain (master)
[12536] 1501112936.255779: Resolving hostname server1
[12536] 1501112936.256379: Sending initial UDP request to dgram server1_ip:88
[12536] 1501112937.257451: Resolving hostname server2
kinit: Invalid argument while getting initial credentials
>
So as you can see server3 is never even tried for authentication. One of my 
theories is that there might be maximum number of kdc's to tryor maximum total 
authentication timeout?! Just a wild guess as I'm reaching for straws. 
---My other question with regards to how sssd and 
krb work together was prompted by sssd.confipa_server= _srv_   option which 
supposed to find available IPA servers from DNS records. We do indeed have this 
option set in sssd.confand are able to resolve server1,server2 server3 when 
querying for following records
_ldap._tcp _kerberos._tcp _kerberos._udp _kerberos-master._tcp 
_kerberos-master._udp _ntp._udp

If the _srv_ is enabled then am i correct in assuming that we wouldn't even 
need kdc= records in krb5.conf ??I tried removing kdc= linesand was unable to 
authenticate.
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: FreeIPA upgrade

[Bhavin Vaidya via FreeIPA-users]

Thanks Rob for pointing out that pki-tps-tomcat is not required. After taking a 
snapshot we remove the RPM and upgraded FreeIPA.

We hit the bug 1436268   , 
so we removed the entry for server_id in /etc/named.conf and all worked out 
great.


regards,

Bhavin



From: Rob Crittenden 
Sent: Monday, July 24, 2017 7:46 AM
To: FreeIPA users list
Cc: Bhavin Vaidya
Subject: Re: [Freeipa-users] FreeIPA upgrade

Bhavin Vaidya via FreeIPA-users wrote:
> Hello,
> We are trying to upgrade FreeIPA- v4.1.3-1.el7 on our master server
> which is CentOS 7.0.1406.
> We were getting other conflict issues, which were fixed with updating yum.
>
> We are not able to go further without following Error, while both RPMs
> in questions are already present and I can same message if tried to
> update pki-server, while for pki-tps-tomcat it says nothing to update.
>
> We have CA certificate on our server ds01.
> We are also not able to add a replica, because of some certificate issue.

I'd fix the certificate issue(s) before trying to upgrade. You are
asking for more trouble trying to upgrade an install that has issues.

>
> [root@ds01 pki-ca]# yum update freeipa-server
>
> 
> --> Finished Dependency Resolution
> Error: Package: pki-tps-tomcat-10.1.2-7.1.el7.centos.noarch
> (@mkosek-freeipa)
>Requires: pki-server = 10.1.2-7.1.el7.centos
>Removing: pki-server-10.1.2-7.1.el7.centos.noarch
> (@mkosek-freeipa)

I don't believe that pki-tps-tomcat is required for IPA. I'm concerned
that you have unofficial bits installed though. Was this to temporarily
work around some issue?

rob

>pki-server = 10.1.2-7.1.el7.centos
>Updated By: pki-server-10.3.3-19.el7_3.noarch (updates)
>pki-server = 10.3.3-19.el7_3
>Available: pki-server-10.3.3-10.el7.noarch (base)
>pki-server = 10.3.3-10.el7
>Available: pki-server-10.3.3-14.el7_3.noarch (updates)
>pki-server = 10.3.3-14.el7_3
>Available: pki-server-10.3.3-16.el7_3.noarch (updates)
>pki-server = 10.3.3-16.el7_3
>Available: pki-server-10.3.3-17.el7_3.noarch (updates)
>pki-server = 10.3.3-17.el7_3
>Available: pki-server-10.3.3-18.el7_3.noarch (updates)
>pki-server = 10.3.3-18.el7_3
>  You could try using --skip-broken to work around the problem
>  You could try running: rpm -Va --nofiles --nodigest
> [root@ds01 pki-ca]# rpm -qa | grep pki-server
> pki-server-10.1.2-7.1.el7.centos.noarch
> dogtag-pki-server-theme-10.1.1-1.el7.centos.noarch
> [root@ds01 pki-ca]# rpm -qa | grep pki-tps-tomcat
> pki-tps-tomcat-10.1.2-7.1.el7.centos.noarch
>
> Thank you and with regards,
> Bhavin
>
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: OSX (El Capitan) - FreeIPA

[Jason Sherrill via FreeIPA-users]

Luiz,

Would you please run the below command from an OS X workstation's terminal
to test look-up/caching of groups? If it displays a gid then we know the
issue isn't LDAP mapping.

dscacheutil -q group -a name *yourGroupName*


On Tue, Jul 25, 2017 at 11:30 AM, Luiz Garrido ALKEMY X via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Our setup is really close to this how-to:
>
> http://www.freeipa.org/page/HowTo/Setup_FreeIPA_Services_
> for_Mac_OS_X_10.12
>
> Just a little different because this didn't exist when we did the
> configuration. But even if you follow that, users on Mac are not getting
> IPA groups and without correct groups, ALCs are not working for those
> workstations.
>
>
>
> Luiz
>
>
>
>
> On 07/25/2017 10:36 AM, Grant Janssen wrote:
>
> Luiz
>
> Oh yes, I had this problem.  But getting functionality on OS-X was not a 
> simple matter.
> Do you have documentation on how you got there?
>
> - grant
>
>
>
>
> On Jul 24, 2017, at 14:16, Luiz Garrido ALKEMY X via FreeIPA-users 
>   
> wrote:
>
> Hi,
>
> We have an environment with mixed OSX and CentOS computers and IPA is
> working great for almost everything.
>
> The only problem that we have (besides the known ones) is that the IPA
> user logged to an OSX computer is not getting group information. Logged
> to a CentOS, the `id` command shows all the groups assigned to the user
> but running the same command on an OSX under the same user, the groups
> are different, mainly Apple groups and not our IPA groups. Does anyone
> had this problem?
>
> So, because of this, ACL permissions on our NFS server is not working
> for OSX machines, but are working great for CentOS ones.
>
> Thanks!
>
> Luiz Garrido
>
> This e-mail and any attachments are intended only for use by the addressee(s) 
> named herein and may contain confidential information. If you are not the 
> intended recipient of this e-mail, you are hereby notified any dissemination, 
> distribution or copying of this email and any attachments is strictly 
> prohibited. If you receive this email in error, please immediately notify the 
> sender by return email and permanently delete the original, any copy and any 
> printout thereof. The integrity and security of e-mail cannot be guaranteed.
>
>
>
> ___
> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
>
>


-- 

*Jason Sherrill*
*IT Specialist*
Deeplocal Inc. 
mobile: 412-636-2073 <(412)%20636-2073>
office: 412-362-0201 <(412)%20362-0201>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Password and OTP auth

[Andrey Dudin via FreeIPA-users]

Hello Christian.

I think about it little bit more and suppose maybe it's not a bug, maybe
it's security feature.

For example:
We have PROD host with OTP auth and user with enabled password and OTP
auth.
Some bad guy stole the user password, go to freeipa web interface, add new
OTP token and go to kill our PROD.


2017-07-26 15:20 GMT+03:00 Christian Heimes :

> On 2017-05-17 12:06, Andrey Dudin wrote:
> > Hello
> >
> > If I do  ipa user-mod test --user-auth-type=password
> > --user-auth-type=otp I have user:
> >
> > [root@ipa-centos]# ipa user-show test
> >   User login: test
> >   First name: test
> >   Last name: test
> >   Home directory: /home/test
> >   Login shell: /bin/sh
> >   Principal name: t...@mydomain.com 
> >   Principal alias: t...@mydomain.com 
> >   Email address: t...@mydomain.com 
> >   UID: 15221
> >   GID: 15221
> >   User authentication types: otp, password
> >   Account disabled: False
> >   Password: True
> >   Member of groups: trust admins, ipausers, admins
> >   Kerberos keys available: True
> >
> > I can login into ipa-client.mydomain.com
> >  to ssh using password+otp token, but
> > for login to IPA Web UI I also need password+otp. I need just password
> > for IPA Web UI and password+otp token for ssh on ipa-client.mydomain.com
> > .
> It's currently not possible to use password-only login when both 2FA and
> password-only are enabled for a user. It's a limitation of the web UI. I
> filed a bug report to track the issue, https://pagure.io/freeipa/
> issue/7068
>
> Regards,
> Christian
>
> --
> Christian Heimes
> Senior Software Engineer, Identity Management and Platform Security
>
> 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
>
>


-- 
С уважением Дудин Андрей
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: OSX (El Capitan) - FreeIPA

[Luiz Garrido ALKEMY X via FreeIPA-users]

Our setup is really close to this how-to:

http://www.freeipa.org/page/HowTo/Setup_FreeIPA_Services_for_Mac_OS_X_10.12

Just a little different because this didn't exist when we did the 
configuration. But even if you follow that, users on Mac are not getting IPA 
groups and without correct groups, ALCs are not working for those workstations.


Luiz



On 07/25/2017 10:36 AM, Grant Janssen wrote:

Luiz

Oh yes, I had this problem.  But getting functionality on OS-X was not a simple 
matter.
Do you have documentation on how you got there?

- grant





On Jul 24, 2017, at 14:16, Luiz Garrido ALKEMY X via FreeIPA-users 

 wrote:

Hi,

We have an environment with mixed OSX and CentOS computers and IPA is
working great for almost everything.

The only problem that we have (besides the known ones) is that the IPA
user logged to an OSX computer is not getting group information. Logged
to a CentOS, the `id` command shows all the groups assigned to the user
but running the same command on an OSX under the same user, the groups
are different, mainly Apple groups and not our IPA groups. Does anyone
had this problem?

So, because of this, ACL permissions on our NFS server is not working
for OSX machines, but are working great for CentOS ones.

Thanks!

Luiz Garrido


This e-mail and any attachments are intended only for use by the addressee(s) 
named herein and may contain confidential information. If you are not the 
intended recipient of this e-mail, you are hereby notified any dissemination, 
distribution or copying of this email and any attachments is strictly 
prohibited. If you receive this email in error, please immediately notify the 
sender by return email and permanently delete the original, any copy and any 
printout thereof. The integrity and security of e-mail cannot be guaranteed.


___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: AD trust setup woes

[Jakub Hrozek via FreeIPA-users]

On Tue, Jul 25, 2017 at 10:12:38AM -0400, Jason Hensley via FreeIPA-users wrote:
> On Tue, Jul 25, 2017 at 2:29 AM, Jakub Hrozek via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> 
> > On Mon, Jul 24, 2017 at 04:25:14PM -0400, Jason Beck via FreeIPA-users
> > wrote:
> > > On Mon, Jul 24, 2017 at 2:53 PM, Jason Beck 
> > wrote:
> > >
> > > > On Mon, Jul 24, 2017 at 2:23 PM, Jakub Hrozek 
> > wrote:
> > > >
> > > >> On Mon, Jul 24, 2017 at 01:53:20PM -0400, Jason Beck wrote:
> > > >> > On Mon, Jul 24, 2017 at 9:25 AM, Jakub Hrozek 
> > > >> wrote:
> > > >> >
> > > >> > > On Mon, Jul 24, 2017 at 09:05:59AM -0400, Jason Beck wrote:
> > > >> > > > On Jul 24, 2017 4:14 AM, "Jakub Hrozek via FreeIPA-users" <
> > > >> > > > freeipa-users@lists.fedorahosted.org> wrote:
> > > >> > > >
> > > >> > > > > On Fri, Jul 21, 2017 at 03:43:58PM -0400, Jason Beck via
> > > >> FreeIPA-users
> > > >> > > > > wrote:
> > > >> > > > > > I have been trying to reliably get an AD trust setup for a
> > few
> > > >> weeks
> > > >> > > and
> > > >> > > > > no
> > > >> > > > > > matter what I try, when I goto add AD users to an external
> > > >> group in
> > > >> > > > > > FreeIPA, I get:
> > > >> > > > > >
> > > >> > > > > > "trusted domain object not found"
> > > >> > > > > >
> > > >> > > > > > Googling around tends to always yield the same suggestions:
> > > >> > > > > >
> > > >> > > > > > 1) Check time sync
> > > >> > > > > > 2) Check DNS
> > > >> > > > > > 3) Check firewall
> > > >> > > > > >
> > > >> > > > > > I have done all of this ad nauseam in several different
> > > >> environments
> > > >> > > with
> > > >> > > > > > several different versions of FreeIPA and Windows servers.
> > I
> > > >> have
> > > >> > > > > gotten a
> > > >> > > > > > setup to work maybe 2% of the time out of hundreds of
> > attempts.
> > > >> > > > > >
> > > >> > > > > > I am currently using FreeIPA 4.5.2 on Fedora 25 (out of the
> > COPR
> > > >> > > repo).
> > > >> > > > > I
> > > >> > > > > > am trying to establish trust with a mixed Windows 2012 &
> > 2008
> > > >> > > forest. I
> > > >> > > > > > have tried both one and two way trusts.  Everything seems to
> > > >> work
> > > >> > > fine up
> > > >> > > > > > until I try to add AD users to FreeIPA.
> > > >> > > > > >
> > > >> > > > > > I have verified all of the requisite DNS records exist and
> > > >> return the
> > > >> > > > > > proper information on both sides, there are no firewalls
> > > >> between any
> > > >> > > of
> > > >> > > > > the
> > > >> > > > > > hosts, and the AD servers and FreeIPA servers are
> > synchronized
> > > >> by the
> > > >> > > > > same
> > > >> > > > > > NTP servers.
> > > >> > > > > >
> > > >> > > > > > What could I possibly be missing?
> > > >> > > > >
> > > >> > > > > Can you resolve the object you're trying to add with sssd?
> > > >> > > > >
> > > >> > > > > e.g. id foo@windows.domain
> > > >> > > > > ___
> > > >> > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahost
> > > >> ed.org
> > > >> > > > > To unsubscribe send an email to freeipa-users-leave@lists.
> > > >> > > fedorahosted.org
> > > >> > > >
> > > >> > > >
> > > >> > > > No.  I can login via Kerberos, kinit user@ad.domain.  But
> > neither
> > > >> id
> > > >> > > > user@ad.domain nor getent passwd user@ad.domain are successful.
> > > >> > >
> > > >> > > Then please follow
> > > >> > > https://docs.pagure.org/SSSD.sssd/users/troubleshooting.html
> > > >> > >
> > > >> >
> > > >> > Jakub,
> > > >> >
> > > >> >   Thank you for the support thus far.  I have followed some
> > suggestions
> > > >> in
> > > >> > the sssd troubleshooting link you provided.  I am seeing these
> > errors
> > > >> > whenever I try to perform an operation that would lookup an AD user,
> > > >> e.g.
> > > >> > id user@ad.domain.  I am performing the user lookups on the
> > primary IPA
> > > >> > server itself.
> > > >> >
> > > >> > *sssd.conf:*
> > > >> >
> > > >> > [domain/ipa.domain]
> > > >> >
> > > >> > debug_level = 10
> > > >> >
> > > >> > cache_credentials = True
> > > >> >
> > > >> > enumerate = False
> > > >> >
> > > >> > krb5_store_password_if_offline = True
> > > >> >
> > > >> > ipa_domain = ipa.domain
> > > >> >
> > > >> > id_provider = ipa
> > > >> >
> > > >> > auth_provider = ipa
> > > >> >
> > > >> > access_provider = ipa
> > > >> >
> > > >> > ipa_hostname = ipa01.ipa.domain
> > > >> >
> > > >> > chpass_provider = ipa
> > > >> >
> > > >> > ipa_server = _srv_
> > > >> >
> > > >> > ldap_tls_cacert = /etc/ipa/ca.crt
> > > >> >
> > > >> > [sssd]
> > > >> >
> > > >> > services = sudo, nss, ifp, pam, ssh, pac
> > > >> >
> > > >> > debug_level = 10
> > > >> >
> > > >> > domains = ipa.domain
> > > >> >
> > > >> > [nss]
> > > >> >
> > > >> > debug_level = 10
> > > >> >
> > > >> > [pam]
> > > >> >
> > > >> > debug_level = 10
> > > >> >
> > > >> > [sudo]
> > > >> >
> > > >> > debug_level = 10
> > > >> >
> > > >> > [autofs]
> > > >> >
> > > >> > debug_leve

[Freeipa-users] Re: Password and OTP auth

[Christian Heimes via FreeIPA-users]

On 2017-05-17 12:06, Andrey Dudin wrote:
> Hello
> 
> If I do  ipa user-mod test --user-auth-type=password
> --user-auth-type=otp I have user:
> 
> [root@ipa-centos]# ipa user-show test
>   User login: test
>   First name: test
>   Last name: test
>   Home directory: /home/test
>   Login shell: /bin/sh
>   Principal name: t...@mydomain.com 
>   Principal alias: t...@mydomain.com 
>   Email address: t...@mydomain.com 
>   UID: 15221
>   GID: 15221
>   User authentication types: otp, password
>   Account disabled: False
>   Password: True
>   Member of groups: trust admins, ipausers, admins
>   Kerberos keys available: True
> 
> I can login into ipa-client.mydomain.com
>  to ssh using password+otp token, but
> for login to IPA Web UI I also need password+otp. I need just password
> for IPA Web UI and password+otp token for ssh on ipa-client.mydomain.com
> .
It's currently not possible to use password-only login when both 2FA and
password-only are enabled for a user. It's a limitation of the web UI. I
filed a bug report to track the issue, https://pagure.io/freeipa/issue/7068

Regards,
Christian

-- 
Christian Heimes
Senior Software Engineer, Identity Management and Platform Security

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



signature.asc
Description: OpenPGP digital signature
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Free IPA/LDAP migration

[Mon Corotan via FreeIPA-users]

I apologize for the confusion. I am referring to 2 servers with two different 
domains. I will try your suggestion and get back for the result.
Thanks for the response :)
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Free IPA/LDAP migration

[Florence Blanc-Renaud via FreeIPA-users]

On 07/26/2017 08:32 AM, Ed Aiduc via FreeIPA-users wrote:

Hi! I'am a newbie here.. I just have a question with regards to LDAP.

I have two free ipa server, one with ldap and the other one has no ldap on it, 
I wanted to transfer/migrate the ldap config from one server to another server 
with no ldap, is it possible?
I'm searching the internet but can't find any source I can use to as reference.
Hoping for your kind response.
Thank you!
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org


Hi,

I am a little bit confused by your question. When an IPA server is 
installed, the LDAP server (389-ds) is installed, configured and 
started. So when you are speaking of one IPA server with no LDAP on it, 
do you mean that you installed an IPA client? If it is the case, then 
you can promote the client from client to server using 
ipa-replica-install command line (see [1]). This will transform your IPA 
client into a replica, ie install the server components and replicate 
the server's data.


Or do you mean that you have 2 servers, each one for a separate domain, 
and you want to migrate the data from server1 to server2? In this case, 
you can use ipa migrate-ds (see [2]).


I may have misunderstood your situation, feel free to clarify if your 
issue is completely different.


Flo

[1] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/install-replica.html
[2] 
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/mig-ldap-to-idm.html

___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

[Freeipa-users] Re: Krb5.conf only sees first two kdc servers

[Sumit Bose via FreeIPA-users]

On Wed, Jul 26, 2017 at 03:56:52AM +, pgb205 via FreeIPA-users wrote:
> As far as I know krb5.conf does not have limitations on the number of KDCs 
> that can be listedhttps://web.mit.edu/kerberos/krb5-1krb5_conf.html
> I have 3 servers that I would like to be read. I have no problem with at 
> least two being listed there.kdc=server1kdc=server2
> when I shutdown server1 authentication happens without trouble against 
> server2.But when I list 3 servers therekdc=server1kdc=server2kdc=server3
> and shutdown server1 and server2 authentication fails.
> My theories about this are:1. there is a variable that specifies max number 
> of kdcs. Seems unlikely2. Bug. Also unlikely3. There is a variable that 
> specifies total number of seconds to wait before giving up.I tried playing 
> with max_timeout and max_retries but that didn't help
> I'm drawing blank as to why only first two kdc lines are honored and would 
> appreciate any advise.

Afaik there is no such limit. I just setup a test realm with for
non-existing KDCs:

 TEST.REALM = {
kdc = 192.168.122.22
kdc = 192.168.122.23
kdc = 192.168.122.24
kdc = 192.168.122.25
 }

and as you can see

# KRB5_TRACE=/dev/stdout kinit abc@TEST.REALM   

  
[26006] 1501051789.950820: Getting initial credentials for abc@TEST.REALM
[26006] 1501051790.24213: Sending request (186 bytes) to TEST.REALM
[26006] 1501051790.24777: Resolving hostname 192.168.122.22
[26006] 1501051790.25215: Sending initial UDP request to dgram 192.168.122.22:88
[26006] 1501051791.26558: Resolving hostname 192.168.122.23
[26006] 1501051791.26948: Sending initial UDP request to dgram 192.168.122.23:88
[26006] 1501051792.28337: Resolving hostname 192.168.122.24
[26006] 1501051792.28956: Sending initial UDP request to dgram 192.168.122.24:88
[26006] 1501051793.30398: Resolving hostname 192.168.122.25
[26006] 1501051793.30832: Sending initial UDP request to dgram 192.168.122.25:88
[26006] 1501051794.32619: Initiating TCP connection to stream 192.168.122.22:88
[26006] 1501051795.34289: Initiating TCP connection to stream 192.168.122.23:88
[26006] 1501051796.36099: Initiating TCP connection to stream 192.168.122.24:88
[26006] 1501051797.37649: Initiating TCP connection to stream 192.168.122.25:88
[26006] 1501051797.138839: Terminating TCP connection to stream 
192.168.122.22:88
[26006] 1501051798.98884: Terminating TCP connection to stream 192.168.122.23:88
[26006] 1501051799.122834: Terminating TCP connection to stream 
192.168.122.24:88
[26006] 1501051800.40306: Sending retry UDP request to dgram 192.168.122.22:88
[26006] 1501051800.146735: Terminating TCP connection to stream 
192.168.122.25:88
[26006] 1501051801.41116: Sending retry UDP request to dgram 192.168.122.23:88
[26006] 1501051802.42920: Sending retry UDP request to dgram 192.168.122.24:88
[26006] 1501051803.44617: Sending retry UDP request to dgram 192.168.122.25:88
[26006] 1501051808.50520: Sending retry UDP request to dgram 192.168.122.22:88
[26006] 1501051809.52449: Sending retry UDP request to dgram 192.168.122.23:88
[26006] 1501051810.54129: Sending retry UDP request to dgram 192.168.122.24:88
[26006] 1501051811.55774: Sending retry UDP request to dgram 192.168.122.25:88
kinit: Cannot contact any KDC for realm 'TEST.REALM' while getting initial 
credentials

all addresses are tried. With what error does the authentication fail? Are
there any details in the logs of kdc3 which might help?

> 
> 
> PS: I would also be interested in more information on relationship between 
> sssd.conf and krb5.conf
> It seems like I can configure sssd.conf with ipa_server=_srv_,  fqdn>  Then why is krb5.conf is necessary at all?

Setting in sssd.conf are typically valid on for SSSD while krb5.conf is used by
all Kerberos clients. But SSSD will create some config snippets which are
included by krb5.conf in /var/lib/sss/pubconf/krb5.include.d/. Those are mainly
about the discovered realms and their relationships discovered by SSSD.

Additionally there is the krb5 locator plugin where SSSD puts the IP address to
the KDC currently used. This was added to make sure a single client keeps
talking to a single KDC to avoid some types of issues. E.g. if you change you
password and immediately try to authenticate again the new password might only
be know on one kdc and not replicated to the others.

There is a known drawback of this approach. If this kdc becomes unavailable to
locator plugin is only updated if SSSD tries to run an operation against this
kdc and fails. Before SSSD updates the plugin all other clients like e.g. kinit
will try to use the kdc returned by the locator plugin because the plugin has a
higher priority than e.g. the settings in krb5.conf which cannot be changed. We
already have a ticket for SSSD to let the locator plugin return more than one
address