Re: [Freeipa-users] Search Base issues
Thanks Martin, can you do SSSD on MAC's?
On Thu, Sep 4, 2014 at 4:45 AM, Martin Kosek wrote:
> Ok, thanks. Good to see it is working for you.
>
> I see you actually do authorization decision based on Schema Compatibility
> plugin :) Note that an alternate, preferred way of doing authorization in
> FreeIPA though is HBAC where you would configure which group of users can
> login
> to which machines.
>
> But this is only being enforced when SSSD is on the client machine, so it
> may
> not be working for all your machines.
>
> Martin
>
> On 09/03/2014 10:45 PM, Chris Whittle wrote:
> > Success here is my LDIF if anyone needs to do this with a MAC
> >
> >> dn: cn=Mac Users, cn=Schema Compatibility, cn=plugins, cn=config
> >>
> >> objectClass: top
> >>
> >> objectClass: extensibleObject
> >>
> >> cn: Mac Users
> >>
> >> schema-compat-search-base: cn=users,cn=accounts,dc=DOMAIN,dc=com
> >>
> >> schema-compat-search-filter:
> >>
> (&(objectClass=posixaccount)(memberOf=cn=canlogin,cn=groups,cn=accounts,dc
> >> DOMAIN,dc=com))
> >>
> >> schema-compat-container-group: cn=compat,dc=DOMAIN,dc=com
> >>
> >> schema-compat-container-rdn: cn=canlogin
> >>
> >> schema-compat-entry-rdn: cn=%{cn}
> >>
> >> schema-compat-entry-attribute: objectclass=inetOrgPerson
> >>
> >> schema-compat-entry-attribute: objectclass=posixAccount
> >>
> >> schema-compat-entry-attribute: gecos=%{cn}
> >>
> >> schema-compat-entry-attribute: cn=%{cn}
> >>
> >> schema-compat-entry-attribute: uid=%{uid}
> >>
> >> schema-compat-entry-attribute: uidNumber=%{uidNumber}
> >>
> >> schema-compat-entry-attribute: gidNumber=%{gidNumber}
> >>
> >> schema-compat-entry-attribute: loginShell=%{loginShell}
> >>
> >> schema-compat-entry-attribute: homeDirectory=%{homeDirectory}
> >>
> >
> >
> >
> > On Wed, Sep 3, 2014 at 1:04 PM, Chris Whittle wrote:
> >
> >> Thanks Rob for the explanation!
> >>
> >> I think I have it working, I just have to test a machine and verify.
> >>
> >>
> >> On Wed, Sep 3, 2014 at 12:47 PM, Rob Crittenden
> >> wrote:
> >>
> >>> Chris Whittle wrote:
> That worked, but having issues get it to work with the OSX Directory
> Utility.
> I'm wondering if it's because when you go against the OU normally it's
> returning more info about the user versus what's being returned from
> the
> compat "view" I'm going to experiment with the attributes it's
> returning
> and see if that's it.
>
> I'm also wondering why FreeIPA doesn't support multiple OU's natively,
> this would be so much easier with multiple OUs (one for my non-users
> and
> one for my users)
> >>>
> >>> Because they are so very often used really, really poorly, resulting in
> >>> having to move entries around a lot with no real technical reason
> behind
> >>> it. Think about the number of times an IT department gets renamed,
> oops,
> >>> today they are called Global Support Services, oh no, didn't you hear,
> >>> now they are ... Each one requiring an entire subtree move. Where the
> >>> users exist in LDAP does not generally need to reflect the
> >>> organizational structure.
> >>>
> >>> Your case is a bit different from most, where you want to host two
> >>> completely separate kinds of users.
> >>>
> >>> rob
> >>>
>
>
> On Wed, Sep 3, 2014 at 9:10 AM, Martin Kosek > wrote:
>
> On 09/03/2014 03:08 PM, Rob Crittenden wrote:
> > Martin Kosek wrote:
> >> On 09/03/2014 09:02 AM, Martin Kosek wrote:
> >>> In the meantime, you can use the workaround that Rob sent, you
> would just need
> >>> to delete it again when the fix is in, so that the permissions
> do not step on
> >>> each other.
> >>
> >> Actually, wait a minute. I think Rob's ACI example may be too
> wide, it may
> >> expose any attribute in the compat tree, including a potential
> userPassword.
> >
> > The ACI was on his custom cn=canlogin subtree, not all of
> >>> cn=compat.
> >
> >> As I see, it seems that slapi-nis plugin do not fortunately
> expose that, but it
> >> is safer to just list the attributes that one wants to display
> (this is also
> >> what we did in FreeIPA 4.0, no global wildcard allowing ACIs
> any
> more).
> >>
> >> I added a respective permission via Web UI (one part of it
> cannot
> be added via
> >> CLI, see https://fedorahosted.org/freeipa/ticket/4522) and
> >>> compat
> tree now
> >> works for me. See attached example.
> >>
> >> Resulting permission shown in CLI:
> >>
> >> # ipa permission-show "TEMPORARY - Read compat tree"
> >> Permission name: TEMPORARY - Read compat tree
> >> Granted rights: read, search, compare
> >> Effective attributes: cn, description, gecos, gidnumber,
> >>
Re: [Freeipa-users] DNS not responding properly....
Check. [root@ipa1 data]# ipa dnszone-show foo.net Zone name: foo.net Authoritative nameserver: ipa1.foo.net. Administrator e-mail address: hostmaster.foo.net. SOA serial: 1400521450 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 Active zone: TRUE Allow query: any; Allow transfer: none; Zone forwarders: 8.8.8.8 [root@ipa1 data]# On 09/05/2014 01:56 PM, Petr Spacek wrote: Hello, On 5.9.2014 18:14, Bret Wortman wrote: I've got an odd situation with one of our networks. Our systems are properly registered in DNS within IPA, and the web interface and IPA queries work to resolve the hosts, but named isn't playing along with us. [root@ipa1 data]# ipa dnsrecord-find foo.net --name=asterisk Record name: asterisk A record: 192.168.252.155 Number of entries returned 1 [root@ipa1 data]# host asterisk.foo.net Host asterisk.foo.net not found: 3(NXDOMAIN) [root@ipa1 data]# cat /etc/resolv.conf search foo.net nameserver 192.168.252.61<- This is ipa1 nameserver 192.168.252.62 nameserver 192.168.252.63 [root@ipa1 data]# ifconfig ens192: flags=4163 mtu 1500 inet 192.168.252.61 netmask 255.255.255.0 broadcast 192.168.252.255 inet6 fe80::250:56ff:fe04:401 prefixlen 64 scopeid 0x20 ether 00:50:56:04:04:01 txqueuelen 1000 (Ethernet) RX packets 2189 bytes 332143 (324.3 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1523 bytes 428925 (418.8 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73 mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10 loop txqueuelen 0 (Local Loopback) RX packets 1037 bytes 718872 (702.0 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 1037 bytes 718872 (702.0 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 [root@ipa1 data]# When I dig into the named.run file, I see the trace below (I ran an "rndc reload" after seeing the request to do so at the end of an earlier section of the file; it obviously didn't help much). I'm not sure where else to look. /etc/named.conf and /var/named/named.ca both are in line with what we have on another similar system where everything is working just fine. Any thoughts? Please double check output from $ ipa dnszone-show foo.net It should contain line like: Active zone: TRUE Petr^2 Spacek 05-Sep-2014 12:04:47.111 received control channel command 'reload' 05-Sep-2014 12:04:47.111 zone 252.168.192.in-addr.arpa/IN: shutting down 05-Sep-2014 12:04:47.112 loading configuration from '/etc/named.conf' 05-Sep-2014 12:04:47.112 using default UDP/IPv4 port range: [1024, 65535] 05-Sep-2014 12:04:47.112 using default UDP/IPv6 port range: [1024, 65535] 05-Sep-2014 12:04:47.113 sizing zone task pool based on 6 zones 05-Sep-2014 12:04:47.116 option 'serial_autoincrement' is not supported, ignoring 05-Sep-2014 12:04:47.194 automatic empty zone: 10.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 16.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 17.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 18.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 19.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 20.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 21.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 22.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 23.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 24.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.194 automatic empty zone: 25.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.195 automatic empty zone: 26.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 27.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 28.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 29.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 30.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 31.172.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 168.192.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 64.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 65.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.196 automatic empty zone: 66.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 67.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 68.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 69.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 70.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 71.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 72.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 73.100.IN-ADDR.ARPA 05-Sep-2014 12:04:47.198 automatic empty zone: 74.100.IN-
