Re: [Freeipa-users] Broken krb5.conf after ipa-server-install
On Wed, 14 Jan 2015, Orion Poplawski wrote:
After running ipa-server-install like this:
ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat
/etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt
--dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXX --http_pkcs12=nwra.com.p12
--http_pin=XXX --idstart=8000
I'm not configuring bind.
I ended up with a broken krb5.conf with entries like:
[libdefaults]
default_realm = #
[realms]
NWRA.COM = {
kdc = server.nwra.com:88
master_kdc = server.nwra.com:88
admin_server = server.nwra.com:749
default_domain = nwra.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
# = {
kdc = server.nwra.com:88
admin_server = server.nwra.com:749
}
[domain_realm]
.nwra.com = NWRA.COM
nwra.com = NWRA.COM
# = #
.# = #
Any idea where the #'s are coming from?
ipa-server-3.3.3-28.el7_0.3.x86_64
/var/log/ipaserver-install.log and ipaclient-install.log have all the
details. You may send them off-list.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Broken krb5.conf after ipa-server-install
On 01/14/2015 04:04 PM, Orion Poplawski wrote:
After running ipa-server-install like this:
ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat
/etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt
--dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXX --http_pkcs12=nwra.com.p12
--http_pin=XXX --idstart=8000
I'm not configuring bind.
I ended up with a broken krb5.conf with entries like:
[libdefaults]
default_realm = #
Probably from the krb5.conf template.
I suspect it means that host name was empty and replacement did not do
anything.
Sounds like host name resolution problem to me.
[realms]
NWRA.COM = {
kdc = server.nwra.com:88
master_kdc = server.nwra.com:88
admin_server = server.nwra.com:749
default_domain = nwra.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
# = {
kdc = server.nwra.com:88
admin_server = server.nwra.com:749
}
[domain_realm]
.nwra.com = NWRA.COM
nwra.com = NWRA.COM
# = #
.# = #
Any idea where the #'s are coming from?
ipa-server-3.3.3-28.el7_0.3.x86_64
--
Thank you,
Dmitri Pal
Sr. Engineering Manager IdM portfolio
Red Hat, Inc.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go To http://freeipa.org for more info on the project
[Freeipa-users] Broken krb5.conf after ipa-server-install
After running ipa-server-install like this:
ipa-server-install -r NWRA.COM -n nwra.com -p `cat /etc/ldap.secret` -a `cat
/etc/ldap.secret` --root-ca-file=PositiveSSLCA2.crt
--dirsrv_pkcs12=nwra.com.p12 --dirsrv_pin=XXX --http_pkcs12=nwra.com.p12
--http_pin=XXX --idstart=8000
I'm not configuring bind.
I ended up with a broken krb5.conf with entries like:
[libdefaults]
default_realm = #
[realms]
NWRA.COM = {
kdc = server.nwra.com:88
master_kdc = server.nwra.com:88
admin_server = server.nwra.com:749
default_domain = nwra.com
pkinit_anchors = FILE:/etc/ipa/ca.crt
}
# = {
kdc = server.nwra.com:88
admin_server = server.nwra.com:749
}
[domain_realm]
.nwra.com = NWRA.COM
nwra.com = NWRA.COM
# = #
.# = #
Any idea where the #'s are coming from?
ipa-server-3.3.3-28.el7_0.3.x86_64
--
Orion Poplawski
Technical Manager 303-415-9701 x222
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] Mount cifs share using kerberos
2015-01-12 10:13 GMT+01:00 Alexander Bokovoy aboko...@redhat.com: On Mon, 12 Jan 2015, John Obaterspok wrote: 2015-01-11 16:33 GMT+01:00 Jakub Hrozek jhro...@redhat.com: On Sun, Jan 11, 2015 at 11:00:16AM +0100, John Obaterspok wrote: 2015-01-10 13:32 GMT+01:00 Gianluca Cecchi gianluca.cec...@gmail.com : To get the whole root environment you have to run su - root did you try with it? ahh... that works fine Gianluca! Final question, if I have a file on the share like: [john@ipaserver mountpoint]$ ll test.txt -rwxr-. 1 root admins 12 11 jan 10.42 test.txt Should I be able to access it if I aquire an admin ticket? Currently I get Permission denied [john@ipaserver mountpoint]$ id uid=143444(john) gid=143444(john) grupper=143444(john) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [john@ipaserver mountpoint]$ getfacl test.txt # file: test.txt # owner: root # group: admins user::rwx group::r-- other::--- [john@ipaserver mountpoint]$ id admin uid=143440(admin) gid=143440(admins) groups=143440(admins) [john@ipaserver mountpoint]$ klist Ticket cache: KEYRING:persistent:143444:krb_ccache_MVjxTqf Default principal: ad...@my.lan Valid starting Expires Service principal 2015-01-11 10:43:52 2015-01-12 10:43:50 krbtgt/my@my.lan [john@ipaserver mountpoint]$ cat test.txt cat: test.txt: Permission denied Looks like your account needs to be in the 'admins' group in order to access the file. Acquiring the admin ticket doesn't switch the user ID nor add you to the group.. I thought the krb5 mount option would allow ticked based access to the file. Is the purpose of the krb5 mount option just used during mounting of the share? Otherwise I see no difference compared to not using krb5 mount option!? Its purpose is authentication. After you have been successfully recognized by the server, both client and server need to map your identity while authorizing your access to actual files. In CIFS there are two types of access control which are applied at the same time: - ACLs per file or directory - POSIX access control based on uid/gid of a process that accesses the file or directory Client-side checks in cifs.ko can be switched off by noperm option. In this case server side will be doing actual access enforcement, using the uid/gid mapped on the server side (based on the Kerberos principal), unless CIFS Unix Extensions were negotiated between cifs.ko and the server. In the latter case client will pass uid/gid of a client to the server and server will do the actual check using them instead of discovering them based on the authentication token. In case where there is a common identity store in use with Kerberos, it is often better to use cifs.ko option multiuser which will imply noperm and server will be doing all the checks. Simo also added that You need to pass the 'multiuser' option at mount time for that, the default for cifs.ko is still to just use the mount credentials. Well, I were actually using multiuser in the original test where I got permission denied but there is something weird going on. mount -t cifs //ipaserver.MY.LAN/Share -o sec=krb5,multiuser mountpoint (I also tried -o sec=krb5,multiuser,cache=none) Anyway, it works if I do the mount as root and then as user john gets the admin ticket *before* going to the share. Then it doesn't matter if I do kdestroy, I can still access a file that would require admin ticket. If I remount the share and go to share as john without admin ticket I can't access a file that would require admin ticket. If I get an admin ticket then I'm still not able to access the file. [john@ipaserver mountpoint]$ ll test.txt -rwxr-. 1 root admins 12 11 jan 10.42 test.txt [john@ipaserver mountpoint]$ cat test.txt Hello World [john@ipaserver mountpoint]$ id john uid=143444(john) gid=143444(john) groups=143444(john),1434400010(mediafiles) [john@ipaserver mountpoint]$ klist Ticket cache: KEYRING:persistent:143444:krb_ccache_Ri45Eiw Default principal: ad...@my.lan Valid starting Expires Service principal 2015-01-14 21:54:24 2015-01-15 21:53:57 cifs/ipaserver.my@my.lan 2015-01-14 21:53:59 2015-01-15 21:53:57 krbtgt/my@my.lan [john@ipaserver mountpoint]$ kdestroy [john@ipaserver mountpoint]$ klist klist: Credentials cache keyring 'persistent:143444:krb_ccache_Ri45Eiw' not found [john@ipaserver mountpoint]$ cat test.txt Hello World [john@ipaserver mountpoint]$ klist klist: Credentials cache keyring 'persistent:143444:krb_ccache_Ri45Eiw' not found - -- then remount share. john has non-admin ticket - [john@ipaserver mountpoint]$ id uid=143444(john) gid=143444(john)
Re: [Freeipa-users] Mount cifs share using kerberos
On Wed, 14 Jan 2015, John Obaterspok wrote: 2015-01-12 10:13 GMT+01:00 Alexander Bokovoy aboko...@redhat.com: On Mon, 12 Jan 2015, John Obaterspok wrote: 2015-01-11 16:33 GMT+01:00 Jakub Hrozek jhro...@redhat.com: On Sun, Jan 11, 2015 at 11:00:16AM +0100, John Obaterspok wrote: 2015-01-10 13:32 GMT+01:00 Gianluca Cecchi gianluca.cec...@gmail.com : To get the whole root environment you have to run su - root did you try with it? ahh... that works fine Gianluca! Final question, if I have a file on the share like: [john@ipaserver mountpoint]$ ll test.txt -rwxr-. 1 root admins 12 11 jan 10.42 test.txt Should I be able to access it if I aquire an admin ticket? Currently I get Permission denied [john@ipaserver mountpoint]$ id uid=143444(john) gid=143444(john) grupper=143444(john) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 [john@ipaserver mountpoint]$ getfacl test.txt # file: test.txt # owner: root # group: admins user::rwx group::r-- other::--- [john@ipaserver mountpoint]$ id admin uid=143440(admin) gid=143440(admins) groups=143440(admins) [john@ipaserver mountpoint]$ klist Ticket cache: KEYRING:persistent:143444:krb_ccache_MVjxTqf Default principal: ad...@my.lan Valid starting Expires Service principal 2015-01-11 10:43:52 2015-01-12 10:43:50 krbtgt/my@my.lan [john@ipaserver mountpoint]$ cat test.txt cat: test.txt: Permission denied Looks like your account needs to be in the 'admins' group in order to access the file. Acquiring the admin ticket doesn't switch the user ID nor add you to the group.. I thought the krb5 mount option would allow ticked based access to the file. Is the purpose of the krb5 mount option just used during mounting of the share? Otherwise I see no difference compared to not using krb5 mount option!? Its purpose is authentication. After you have been successfully recognized by the server, both client and server need to map your identity while authorizing your access to actual files. In CIFS there are two types of access control which are applied at the same time: - ACLs per file or directory - POSIX access control based on uid/gid of a process that accesses the file or directory Client-side checks in cifs.ko can be switched off by noperm option. In this case server side will be doing actual access enforcement, using the uid/gid mapped on the server side (based on the Kerberos principal), unless CIFS Unix Extensions were negotiated between cifs.ko and the server. In the latter case client will pass uid/gid of a client to the server and server will do the actual check using them instead of discovering them based on the authentication token. In case where there is a common identity store in use with Kerberos, it is often better to use cifs.ko option multiuser which will imply noperm and server will be doing all the checks. Simo also added that You need to pass the 'multiuser' option at mount time for that, the default for cifs.ko is still to just use the mount credentials. Well, I were actually using multiuser in the original test where I got permission denied but there is something weird going on. Nothing weird (tl;dr). mount -t cifs //ipaserver.MY.LAN/Share -o sec=krb5,multiuser mountpoint (I also tried -o sec=krb5,multiuser,cache=none) Anyway, it works if I do the mount as root and then as user john gets the admin ticket *before* going to the share. Then it doesn't matter if I do kdestroy, I can still access a file that would require admin ticket. If I remount the share and go to share as john without admin ticket I can't access a file that would require admin ticket. If I get an admin ticket then I'm still not able to access the file. Kerberos authentication happens when you first access the share as a new user -- cifs.ko will ask userspace to provide Kerberos credentials to the kernel so that negotiation can happen. Once it is done, the credentials are valid until the actual Kerberos ticket expires or until session expires. So when you access file as john while having admin ticket, you get admin ticket used for multiuser access. Destroying ccache does not affect already performed negotiation. When you remount, previous credentials that cifs.ko used are cleaned, thus cannot be used. If you try to access the mount point as 'john' without Kerberos credentials, you'd be negotiating anonymous connection which would only succeed if the share is allowed to connect to anonymously (guest ok = yes). However, you accessed the share with john Kerberos credentials. These credentials were negotiated and will be valid until the connection is dropped or ticket expires, whichever event comes first. In fact, cifs.ko expires sessions periodically but I was unable to find exact expiration time myself. -- / Alexander Bokovoy -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To
[Freeipa-users] FreeIPA for Debian Wheezy, Ubuntu 12.04
Hi List Please is it really possible to have Debian and Ubuntu serve as IPA clients? I've tried some instructions/guidelines on the list and they always fail with the IPA client install being halfway completed and sssd's configuration file moved to .deleted. I'm really interested in getting this to work and I'll appreciate any help I can get. Failing that are there any alternatives? Thanks! -- 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] Problems with ntpd when running FreeIPA in a Docker container
Hi, I'm running into a strange problem related to ntpd when trying to use IPA in a container. I'm using the adelton/freeipa-server:fedora-21 and adelton/freeipa-client:fedora-21 docker images. Basically, the client install hangs when it runs ntpd. This is reproducible on two different docker hosts of mine, so it will probably easily reproduce for others as well. Below are the steps I'm using. Install IPA server in F21 container: [root@localhost ~]# docker run --name freeipa-server-container -d -h ipa.example.test -e PASSWORD=Secret123 adelton/freeipa-server:fedora-21 875007ab561ff62ea45dde5e8a5e320a209c63b3c8fc52bd4ca7b22561d1bbf0 [root@localhost ~]# docker logs freeipa-server-container ... FreeIPA server configured. Go loop. Install IPA client in F21 container and link it to the IPA server container. This will hang indefinitely when it tries to run ntpd to sync the time before getting the admin ticket: [root@localhost ~]# docker run --name client -h client.example.test --link freeipa-server-container:ipa -e PASSWORD=Secret123 -e IPA_CLIENT_INSTALL=--debug -it adelton/freeipa-client:fedora-21 ... Synchronizing time with KDC... Search DNS for SRV record of _ntp._udp.example.test DNS record found: 0 100 123 ipa.example.test. Starting external process args='/usr/sbin/ntpd' '-qgc' '/tmp/tmpRhhyCz' If I use nsenter to go into the client container and kill ntpd, the install continues and completes. I also confirmed that the ntpd config file that we create in /tmp is correct. From within the client container (via nsenter), running 'ntpd -qgc' with a conf file that points to the IPA server just loops endlessly. I looked into the IPA server container, and ntpd is not running. The ipaserver-install.log shows that it attempts to start (which returns 0), but the service is not active afterwards: ... 2015-01-14T22:57:02Z DEBUG [4/4]: starting ntpd 2015-01-14T22:57:02Z DEBUG Starting external process 2015-01-14T22:57:02Z DEBUG args='/bin/systemctl' 'start' 'ntpd.service' 2015-01-14T22:57:03Z DEBUG Process finished, return code=0 2015-01-14T22:57:03Z DEBUG stdout= 2015-01-14T22:57:03Z DEBUG stderr= 2015-01-14T22:57:03Z DEBUG Starting external process 2015-01-14T22:57:03Z DEBUG args='/bin/systemctl' 'is-active' 'ntpd.service' 2015-01-14T22:57:04Z DEBUG Process finished, return code=3 2015-01-14T22:57:04Z DEBUG stdout=inactive 2015-01-14T22:57:04Z DEBUG stderr= 2015-01-14T22:57:04Z DEBUG duration: 1 seconds 2015-01-14T22:57:04Z DEBUG Done configuring NTP daemon (ntpd). ... It seems that this causes ntpd on the F21 client to just loop endlessly since it never sees a response. We use ntpdate on F20, which bails out and skips the time update on a F20 client when the server is unavailable: ... 2015-01-15T03:29:11Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v ipa.example.test 2015-01-15T03:29:11Z DEBUG Process finished, return code=1 2015-01-15T03:29:11Z DEBUG stdout= 2015-01-15T03:29:11Z DEBUG stderr= 2015-01-15T03:29:11Z DEBUG Starting external process 2015-01-15T03:29:11Z DEBUG args=/usr/sbin/ntpdate -U ntp -s -b -v ipa.example.test 2015-01-15T03:29:11Z DEBUG Process finished, return code=1 2015-01-15T03:29:11Z DEBUG stdout= 2015-01-15T03:29:11Z DEBUG stderr= 2015-01-15T03:29:11Z WARNING Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. ... I can do a 'systemctl start ntpd.service' on the IPA server container, and it does start up successfully. It never seems to automatically start though, even if I restart the IPA server docker container. I did confirm that ntpd.service is enabled with systemctl, yet it doesn't start automatically. The /sbin/ipa-server-configure-first entrypoint script for the server image does a 'systemctl start-enabled' to bring up all of the services, which results in this output in /var/log/systemctl.log: [start-enabled] [start ntpd.service] Running [export OPTIONS=-g -x; /usr/sbin/ntpd -u ntp:ntp $OPTIONS] Marked pid [15] for [ntpd.service] Marked process name [/usr/sbin/ntpd] for [ntpd.service] ... This is the same log output that is generated if I manually run 'systemctl start ntpd.service' from within the container, but the ntpd process stays around when I start it this way. It's hard to tell what might be happening to ntpd, as
Re: [Freeipa-users] Redhat/Centos iDM 3.0 to 3.1 upgrade fail
Hi, I need some information from you. Which versions of the PKI packages that you are using on the CentOS 6.6 and 7.0 machines? Could you email me the PKI CA debug logs (/var/log/pki-ca/debug or /var/log/pki/pki-tomcat/ca/debug) from both machines? There's a possibility it may be related to this ticket: https://fedorahosted.org/pki/ticket/1235 Thanks. -- Endi S. Dewata On 1/13/2015 7:59 PM, Jim Richard wrote: Carefully following the instructions here: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/upgrading.html I have split one of my Centis 6.6 based replicas from the main cluster of 4 IDM servers, fully disconnected it from current IDM infrastructure, converted it to a master CA, double checked that I have no dangling/tombstone entries pointing back to other cluster members, ipa-replica-manage list and ipa-replica-manage list-ruv both show no other masters, in short, made absolutely sure that this replica is now a standalone. I then applied the schema updates via the python script per the above referenced instructions, did “ipa-replica-prepare”, deployed a new Centos 7 vm, yum install ipa-server there, scp’d over the replica file. Next up, ipa-replica-install --setup-ca”. And that’s where the story ends….. Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/19]: creating certificate server user [2/19]: configuring certificate server instance ipa : CRITICAL failed to configure ca instance Command '/usr/sbin/pkispawn -s CA -f /tmp/tmpM9BzPz' returned non-zero exit status 1 Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Configuration of CA failed I tried the workaround mentioned here: https://fedorahosted.org/pki/ticket/816 updated /usr/share/pki/ca/conf/CS.cfg before running ipa-replica-install But not luck. Anybody have a clue where I should look? From pki-ca-spawn.20150114014019.log: 2015-01-14 01:40:32 pkispawn: ERROR... Exception from Java Configuration Servlet: Failed to obtain installation token from security domain and in /var/log/pki/pki-tomcat/ca/server I have: 2754.localhost-startStop-1 - [14/Jan/2015:01:40:29 UTC] [3] [3] Cannot build CA chain. Error java.security.cert.CertificateException: Certificate is not a PKCS #11 certificate 2754.localhost-startStop-1 - [14/Jan/2015:01:40:29 UTC] [13] [3] authz instance DirAclAuthz initialization failed and skipped, error=Property internaldb.ldapconn.port missing value more info that might help……. [root@sso-centos7 pki]# certutil -L -d /var/lib/pki/pki-tomcat/alias Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI Server-Cert cert-pki-ca CTu,Cu,Cu Certificate Authority - PLACEIQ.NET http://PLACEIQ.NET CT,c, My CS.cfg is attached. Maybe the fact that my new server is looking at the same DNS and can see the SRV records for the current Centos 6.6/IDM 3.0 cluster is causing a problem ?? Of course I have uninstalled and done this a zillion times: pkidestroy -s CA -i pki-tomcat rm -rf /var/log/pki/pki-tomcat rm -rf /etc/sysconfig/pki-tomcat rm -rf /etc/sysconfig/pki/tomcat/pki-tomcat rm -rf /var/lib/pki/pki-tomcat rm -rf /etc/pki/pki-tomcat I’m at a loss, no idea even where to look at this point. Thanks in advance for any clues you can provide. Jim Richard | PlaceIQ http://www.google.com/url?q=http%3A%2F%2Fwww.placeiq.com%2Fsa=Dsntz=1usg=AFrqEzcYjZpDPyqW7feNK9EgLq-c9JlHiw | Systems Administrator | jrich...@placeiq.com mailto:n...@placeiq.com | +1 (646) 338-8905 -- 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] Password policy for admin account not working
Thank you Rob. That makes sense but I could have sworn I changed the policy before expiration. Resetting it did indeed resolve the issue though. Sorry for the headache. On Mon, 1/12/15, Rob Crittenden rcrit...@redhat.com wrote: Subject: Re: [Freeipa-users] Password policy for admin account not working To: sipazzo sipa...@yahoo.com, Freeipa-users@redhat.com Freeipa-users@redhat.com Date: Monday, January 12, 2015, 11:48 AM sipazzo wrote: Good morning, I created a service password policy that prevents password expiration and gave it a priority of 0. I then created a service user group and applied the policy to the group. I added my admin user to this group so their password would not expire. However, it continues to expire anyway. I have other (not built-in) accounts that use this policy successfully so it seems like the priority is not working correctly. I am unable to change the priority on the global_policy. Is my only option to add another policy with the same config as the global policy but a lower priority and assign that to all my users? Password policy for expiration is applied at the time the password is changed/set, not retroactively, so you may just need to reset the password on those accounts. To see what policy will be applied to a give user do: $ ipa pwpolicy-show --user=someuser rob -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] FreeIPA 4.1, OSX 10.9 and secondary groups
Hola, This is a response to: https://www.redhat.com/archives/freeipa-users/2014-October/msg00126.html Scott, maybe you already found the solution, but I've been banging my head with the same problem, albeit with a newer version of FreeIPA and OSX. I used this excellent howto to get started: http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 Despite initial success, without secondary groups the OSX integration doesn't really make sense. I managed to get it working though, by doing this: In the Search Mappings area of Directory Utility, change the Search base of the Groups record type from 'cn=groups,cn=accounts,dc=example,dc=com' to 'cn=groups,cn=compat,dc=example,dc=com' ( so compat instead of accounts). In Groups add the attribute 'GroupMembership' mapped to 'memberUID'. You might have to map to 'member' in FreeIPA 3.0. With these settings, doing an 'id user' on OSX shows all secondary groups, even indirect group membership! I still have to test and figure stuff out about ssh and sudo on the OSX side of things, but that isn't as important as having group access control. Hope it helps! Best regards, Ejner Fergo -- 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 I revert back the hostname on client
On 01/14/2015 03:38 AM, Petr Spacek wrote: Hello, On 14.1.2015 06:13, Rakesh Rajasekharan wrote: Freeipa changes the hostname to FQDN. But in our exisitng set up that can cause issues . Could you be more specific? It would help if we had detailed bug reports about this but up to know everybody just said 'I need non-FQDN hostname' but did not add any details :-) What doesn't work? Can I revert back the hostname to previous value once the client installation is complete. You might see all sorts of breakages related to Kerberos, sorry. I am fine with server having a FQDN. You can tell SSSD to use a different hostname instead of the one the host actually uses. See SSSD man pages for that. You might also need to do a similar thing with krb5.conf by setting dns_canonicalize_hostname and make sure your DNS can actually resolve the short hostnames to FQDNs -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] FreeIPA 4.1, OSX 10.9 and secondary groups
On 01/14/2015 01:11 PM, Ejner Fergo wrote: Hola, This is a response to: https://www.redhat.com/archives/freeipa-users/2014-October/msg00126.html Scott, maybe you already found the solution, but I've been banging my head with the same problem, albeit with a newer version of FreeIPA and OSX. I used this excellent howto to get started: http://linsec.ca/Using_FreeIPA_for_User_Authentication#Mac_OS_X_10.7.2F10.8 Despite initial success, without secondary groups the OSX integration doesn't really make sense. I managed to get it working though, by doing this: In the Search Mappings area of Directory Utility, change the Search base of the Groups record type from 'cn=groups,cn=accounts,dc=example,dc=com' to 'cn=groups,cn=compat,dc=example,dc=com' ( so compat instead of accounts). In Groups add the attribute 'GroupMembership' mapped to 'memberUID'. You might have to map to 'member' in FreeIPA 3.0. With these settings, doing an 'id user' on OSX shows all secondary groups, even indirect group membership! I still have to test and figure stuff out about ssh and sudo on the OSX side of things, but that isn't as important as having group access control. Hope it helps! Best regards, Ejner Fergo Thanks for sharing! So this seems to mean that Mac expects 2307 schema instead of the 2307bis. So yes pointing to compat tree would be the right approach. Can we document it somethere? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] DNS updates from dhcpd refused
On 13.1.2015 21:25, Dmitri Pal wrote: On 01/13/2015 01:41 PM, Mike wrote: On Tue, 13 Jan 2015, Dmitri Pal wrote: On 01/13/2015 12:35 PM, Mike wrote: Just a note to anyone else who may be interested. This may be obvious but it wasn't to me at first, The ipa dnszone-mod ... --update-policy=... command wipes out the existing BIND update policy. So what would seem to me to be the correct procedure is to do ipa dnszone-show --all first to get the existing policy. Then append the new policy to the existing. This is what ultimatley worked for me (all one line). ipa dnszone-mod inside.lan --update-policy=grant INSIDE.LAN krb5-self * A; grant INSIDE.LAN krb5-self * ; grant INSIDE.LAN krb5-self * SSHFP; grant dhcpupdate zonesub A; grant dhcpupdate zonesub TXT; grant dhcpupdate zonesub PTR; Would you mind contributing a howto solution to FreeIPA site? Wouldn't mind at all however the Howto I used (http://www.freeipa.org/page/Howto/DNS_updates_and_zone_transfers_with_TSIG) is mostly correct, only three errors that I'm aware of. And it is a bit brief, there are a few things I could add. Should I just follow up off list with updates/changes? -- Mike Thanks! Petr, Martin, what do you think is the best approach, for Mike just edit the page or send corrections off list? Mike, don't hesitate to update the page directly. After all, it has a history so we can review it post-edit. Personally I don't want to set up some heavy-weight review process for wiki :-) -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
Re: [Freeipa-users] Can I revert back the hostname on client
Hello, On 14.1.2015 06:13, Rakesh Rajasekharan wrote: Freeipa changes the hostname to FQDN. But in our exisitng set up that can cause issues . Could you be more specific? It would help if we had detailed bug reports about this but up to know everybody just said 'I need non-FQDN hostname' but did not add any details :-) What doesn't work? Can I revert back the hostname to previous value once the client installation is complete. You might see all sorts of breakages related to Kerberos, sorry. I am fine with server having a FQDN. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go To http://freeipa.org for more info on the project
[Freeipa-users] SASL GSSAPI behavior change in RHEL 7
This is not exactly the right place to post this message, but I reckon it is close enough. A year or so ago, I wrote up a guide for configuring a Postfix client to use Kerb/GSSAPI to authenticate against a Postfix server acting as a relay. The guide is here: https://stomp.colorado.edu/blog/blog/2013/07/09/on-freeipa-postfix-and-a-relaying-smtp-client/ and it is linked somewhere on the FreeIPA pages. It was written for RHEL 6.x Everything worked fine and I forgot everything I ever learned to write the guide :). With the release of RHEL 7 I am again going back through the process of validating that things work as I believe they should etc. Trying to configure up this same setup with RHEL 7 is however, proving to be problematic. The configuration directives have not changed and everything should in theory work, however it simply doesn't. My basic layout is as follows, RHEL 7 Postfix client attempting to relay through a RHEL 6 Postfix server using Kerberos. SASL appears to be bailing when attempting to use GSSAPI for auth with the Postfix server. The specific error is: warning: SASL authentication failure: GSSAPI Error: A required input parameter could not be read (Unknown error) Which means all of nothing to me. However, I found the following bug in Cyrus' bugzilla: https://bugzilla.cyrusimap.org/show_bug.cgi?id=3480 Essentially mentioning the same thing, and mentioning that this error is cropping up in a few places (autofs is mentioned). The specific commit they reference is here: http://git.cyrusimap.org/cyrus-sasl/commit/?id=080e51c7fa0421eb2f0210d34cf0ac48a228b1e9 I don't know whether this is an incompatibility, I don't know whether running against a RHEL 7 Postfix server will help in any way. I actually don't know much of anything about this, and hence wanted to ask for thoughts from folks who may be more in the know than I am. Any ideas what this is all about? Any thoughts about possible solutions? -Erinn signature.asc Description: This is a digitally signed message part. -- 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] invalid cn=CACert,cn=ipa,cn=etc entry
On 01/13/2015 04:53 PM, Bram Vandoren wrote: Hi All, We run a FreeIPA server (3.0.0) on SL6. Fedora 21 clients are unable to complete freeipa-client-install. It fails due to a parsing error of the CA certificate. I tracked down the error and it seems our cn=CACert,cn=ipa,cn=etc entry is invalid. This is the ldif: dn: cn=CACert,cn=ipa,cn=etc,dc=xyz,dc=abc, dc=de objectClass: top objectClass: pkiCA objectClass: nsContainer cn: CAcert cACertificate;binary:: (this fields contains base64 encoded data, not binary data) I modified the certstore.py script and changed line 299 from cert = entry.single_value['cACertificate;binary'] to: cert = base64.b64decode(entry.single_value['cACertificate;binary']) after that ipa-client-install completes without a problem. We run FreeIPA for a few years now so perhaps something went wrong with an update of the server at some point and the cn=CACert entry was not updated correctly. Hello Bram, Good investigation! You already found the root cause. You are most possibly hitting https://bugzilla.redhat.com/show_bug.cgi?id=948928 that is fixed in ipa-3.0.0-30.el6 or later. What's the valid format of the CACert entry in LDAP? Can we change it to binary without other clients ending up in trouble? Yes. It is supposed to be in binary, as even the attribute name cACertificate;binary suggests. If you fixed the certificate or removed the attribute and let LDAP updater do it's job and re-upload it correctly, you should be fine. Guessing from the get_ca_certs function we also want other attributes like ipaCertSubject, ipaCertIssuerSerial,... These are also missing in our server but perhaps these were only added in later FreeIPA server versions. These were added for FreeIPA 4.1, as part of tickets https://fedorahosted.org/freeipa/ticket/3259 https://fedorahosted.org/freeipa/ticket/3520 You do not need to worry about them for clients/servers older than 4.1. HTH, 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] I think I trashed my FreeIPA CA - how to recover?
Hi Martin, thanks for your response! What I realize now is the certificate CRL points to the server that no longer exists and I'd like to get that cleaned up. I found http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master http://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master, is that relevant for my situation? Yes, this is the procedure to follow for servers older than FreeIPA 4.1. Jan is that correct? If yes, the page deserves a warning/update. Ooof! I forgot that vendor repos were so far behind. I'm still at 3.3.3-28. Is it reasonable and desirable to run one of my two servers with the image documented at http://seven.centos.org/2014/12/freeipa-4-1-2-and-centos http://seven.centos.org/2014/12/freeipa-4-1-2-and-centos? I'm interested in integrating Shiro or some other RBAC against IPA at some point in the next few months, but I'd wait if the Docker image is a prelude to 4.x hitting vendor repos soon. Cheers, Brian-- 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
