Waitin' For A Minute, Till' The Sun Sees Through My Eyes
in which Bubble adopts a dying rose bush
debut of the alliance! or the rest of them anyway lol
bit of a slow chapter but sometimes thats just how it goes
ch 2/?
AO3
The Yoyle Needle was absolutely massive , standing taller than any other building in the city, making it a good landmark to orient yourself with, particularly when you spent most of your time there anyway. It had seemed a bit intimidating at first, all things considered, but after a while, it simply blended into the background. It became normal.
As it’s base came into view, Bubble spotted her friends clustered on the sidewalk near the door. Ruby and Book sat on the edge in the midst of a heated thumb war, Ice Cube playing referee. Pencil and Match leaned against the wall, spectating. Ice Cube piped up, though what exactly she said was lost on her as Ruby threw her arms up and cheered, seemingly victorious. Match glanced in Bubble’s direction and smiled, waving.
“Hey Bubs!”
Everyone turned towards her as she approached.
“Hoi goirls! Hope I didn’t keep you waiting.”
“Nope,” Ruby chirped, snatching her Shirly temple from the tray. “we just got here!” She plucked the cherry off the top and popped it into her mouth, tossing the stem over her shoulder and into the street as book passed Ice Cube her cherry cola before sipping her own apple juice. Match took both the iced coffee and iced tea, passing the former to Pencil, who gave them both a small smile of thanks before sipping it.
“I still down know how Gelatin learned to make any of this stuff,” Pencil said, looking at the crude drawing of Gelatin on the cup, “I don’t even think I’ve seen him in a kitchen before.”
As much as she liked his drinks, Bubble was equally curious. Back in his steakhouse, she simply assumed there were chefs preparing the meals while he milled about the restaurant talking to customers, but the drink stand he’d opened when they moved put a hole in that theory. Every Wednesday, when it was her turn to get the morning drinks, he would spend several minutes standing by the window chatting with her idly after she’d ordered before turning around for mere seconds and returning with the drinks. She could see straight to the back from where she stood, which was empty with the exception of Gelatin himself, who, when pressed, only ever answered that he was “just that good”.
Taking the remaining strawberry lemonaid and sipping it, she decided, perhaps, that she didn’t want to know. She tossed the empty tray in the nearby bin.
Bubble sipped her lemonaid, halfway through the cup when Ruby piped up
“So, what’re we doing today?”
“Pencil and I are, like, going downtown to look for a camera”
“What do you need a camera for?” Book asked.
Pencil swirled what little coffee was left in her cup
“We’re gonna start a vlog series, ” She replied, “Don’t want our fans to miss us too much.”
“Oh, wow, neat! Ice cube and I are gonna try baking yoyleberry pie again.”
Ice Cube smiled as Book said her name, glancing at her with soft eyes as she drank the last of her soda. Pencil glanced between them, smirking.
“Just don’t, like, make a mess of the kitchen again”
“Oh, come on, it wasn’t that bad.” Book replied.
Match scoffed.
“Like, as if. There was flower everywhere for, like, a week!”
“It was only a day , Match, and—”
Ruby stuck herself between the two, cutting them off before they could jump at each other’s throats
“What about you, Bubble? What’re you up to today?”
Bubble jumped at her name. She hadn’t been focusing on the conversation, finding herself studying the droplets of condensation on her cup run down and land on top of her hand. The sorrowful little rose bush was burned into her mind, a pang of odd guilt chiming in at the thought. Perhaps she shouldn’t have left it behind, she thought, not when it so badly needed help, but—
She shook it off, turning to Ruby.
“Woil, I wointed to do some gardening, but oim not sure…”
“Why not?”
“Oi need to move a plant woith thorns and”— Bubble glanced away—“I dont wonna pop.”
She sipped the last of her lemonaid as Ruby smiled.
“Oh! If thats all, then I can help you out!”
“Roilly? But aren’t you busy?”
“Not really,” Ruby shrugged, “and I like helping you garden anyway!”
Again, Pencil smirked at the two of them as Bubble beamed wide.
Noon had hit by the time Bubble returned to the alleyway, this time with Ruby in tow. Despite the sun’s position the area was still cast in a cool shade by the buildings towering on every side. They stopped just in front of the withered old rose bush, crumpled at their feet. Somehow its seemed even worse for wear then before.
“Yeah, that doesn’t look good,” Ruby said.
Bubble hummed, kneeling down and inspecting a leaf. “It’s not getting enough sunloight over here. Oi wanna move it, but—”
“Say no more!”
Ruby knelt down and reached for the pot, scraping her hands a bit in the process. Pale brown roots caught Bubble’s eye as she began hefting the plant into the air. They stretched between the sidewalk and the pot.
“Roiby wait! Your gonna break the roots!”
She paused. A sprinkle of soil fell from the pot and into the large crack in the ground the roots had dug themselves into.
“Oh. Sorry.”
“Its ok.”
Ruby returned the pot to its place over the hole.
“So what do we do now?”
“Hmmm, well”—Bubble stood up, Ruby following suit—“if we had a shovel, oi could try digging them up.”
“But I thought you hadn’t brought all your gardening stuff here yet?”
Turning back, Bubble peered around the corner, scanning the abandoned buildings carefully. A restaurant, a shipping outpost, a toy store stood across the street, flanked on the left by a pharmacy and on the right by a—
“Oh! That plant shop moight have some!”
9 notes
·
View notes
Things I’ve Learned: FreeIPA
I've been a user of FreeIPA for quite a long time, mostly in home and lab environments that didn't really have any bearing on enterprise environments. I always saw it as a sort of Active Directory (it's not) for Linux and UNIX systems and used it to test various things. One example of using it to test "things" was practicing for my RHCE in 2016 and also studying my Red Hat Security Hardening. Now I've used it since version 3.0, and it definitely has come a long way since then. I never really took a lot of the time I thought was necessary to learn specific things about it, in terms of having it work with an Active Directory and even 2FA/OTP among other things. Many years ago, there were functions such as winsync (which is now deprecated) that helped with this, while even the sssd components began to slowly integrate Active Directory support directly.
To give some backstory to the title of this post: In my current job, we are a mixed environment shop. We have a handful of Windows, Linux, and UNIX systems. Because of this, we have two separate directory servers. We have an LDAP and an Active Directory. A few years back, I respawned conversations that were shut down by previous management: We need to consolidate directory servers into at least Active Directory. Practically all of our workstations run Windows or Mac. Our usernames between both directories are different (LDAP uses underscores between first and last names, AD had first initial, last name up to 7 characters and now it's first.last). You can imagine how confusing this is and how annoying this actually is.
You can imagine the challenges this brings. In fact, here's a list of challenges this poses for the organization.
New users get confused and think they login with user.name@domain, domain\user.name, user.name on Linux/UNIX systems
Users at times do not know what username is used for what application or system (is it user_name or user.name for $x?)
Introduction of OIM (oracle identity manager) and OAM (oracle access manager), which was setup incorrectly and managed poorly by incompetent team called "information security"
Now you might wonder why does this matter to my FreeIPA topic. Simple, it causes issues for the UNIX engineering team (which I now co-lead).
Managers and above as well as new users expect all their access to be already there for all Linux/UNIX systems they need to work on
Again, new users get confused and use AD usernames to login to Linux/UNIX systems
Access is defined on their LDAP objects as "host: hostname"
SUDO is hybrid: LDAP and /etc/sudoers.d files
Identity management tools, which have been in the environment for almost 4 years, were never designed to handle the above
Management is reluctant to go to "member" groups to define access to systems (to emulate "role based" access)
This is where I stepped in and suggested that we need to use a different product, even though I initially suggested we go to AD entirely. The problem with going to AD entirely is that it takes away the UNIX team's management, and plus we would probably need to buy other products or software just to get group policies to work. This did not sit well with majority of my team and I didn't like the idea either, especially because we then begin to lose a sense of control on our own systems. This is when I suggested FreeIPA, as FreeIPA at the time (version 4.4) supported IPA-AD trusts. This meant that it gave control back to the UNIX team to our own infrastructure. Logins would be from our AD, we wouldn't need to create accounts in FreeIPA. This reduces a lot of overhead on us, leaving LDAP to start to (hopefully) die off. My team as a whole agreed to the idea so I took the project and started it up.
This is what I've learned and achieved.
The Setup
The setup was easy for me. The network team delegated me a subdomain of one of our internal domains to make my life easier. The Windows team was also extremely helpful and helped me get the AD trust up. I didn't expect it to be a pain, as my tests at home succeeded. The trust was setup, enabling compat and posix attributes (uidNumber, gidNumber, unixHomedirectory, loginShell) to try and make the migration from LDAP to IPA easier. The Windows engineer also setup my team as well as two other teams with the attributes so I had a biggger test bed.
After doing this, I also set the domain resolution order (FreeIPA 4.5) to be the AD domain first. That way, logging in with just user.name without the @domain works without much an issue. And then, clients using sssd had full_name_format set to %1$s to make it less confusing for users on their prompts. I didn't like the idea of having a prompt like
[email protected]@servername - that's extremely annoying to look at. When this is set, you are able to do id for users in both AD or IPA without the domain on the name and it succeeds on RHEL 7 and higher. Setting domain resolution order back to blank or not setting it at all will require the @domain to be used for logins, including in the compat tree. There's really no other clear way around this as far as I know.
SID Numbers
The issue with trying to do a cleanish migration is that you can't change gid numbers out from under people. FreeIPA creates a range for your domain and also creates a range for AD, even if you don't use it/you're using posix attributes. When you create groups outside of IPA's defaulted range, they will not receive SID numbers. In this case, I had to create another range and then rerun the proper SID generating scripts.
I created a range with this data:
Base ID: 10
Range size: 50000
Primary RID base: 200000000
Secondary RID base: 200050000
I then did an update across the board. This took a little bit.
# cat > /root/task/80-sidgen-task-conf.uipdate <<EOF dn: cn=$TIME-$FQDN,cn=ipa-sidgen-task,cn=tasks,cn=config add:objectClass: top add:objectClass: extensibleObject add:cn:$TIME-$FQDN add:nsslapd-basedn: $SUFFIX add:delay: 0 EOF # ipa-ldap-updater /root/task/80-sidgen-task-conf.update
SUDO
SUDO for clients older than RHEL 7 was very interesting when in a IPA-AD trust.
Legacy Clients
Our environment is ridiculously mixed. We have Solaris 8, 10, 11, RHEL 5, 6, and 7. We also have Fedora workstations that my team uses because we dislike Windows, but that's a different story. We have still been trying to get rid of Solaris 8 forever now, but without any movement. We decided to not attach Solaris 8 to FreeIPA to hopefully let the systems rot.
RHEL 5
"RHEL 5???" you might be thinking. Yes. It's been out of support since March 31, 2017. This company has no concept of anything "new" or wanting to get rid of technology debt. So since we were probably going to be stuck with RHEL 5 for another year or so, I had to figure out how to get it to connect to FreeIPA - not only as a client but also be able to see Active Directory users. The first thing I learned here: Always use the ipa-advise command - Seriously. This will help you out so much.
In my case, I used nss pam ldap to help here. What this provided at the very least is the ability to get sudo to actually work 100% of the time - sudo didn't work all the time when sssd was the id provider. Here's the issue:
The domain resolution order configuration causes multiple uid attributes to appear on objects in the compat tree - this is normal.
Group membership, even in the compat tree, is defined by
[email protected], rather than just user. As far as I know, there's no clear way around this. Running groups or id will not show proper membership.
sudo probably only worked here because of the id output, even though I was logging in with first.last, my id shows up as
[email protected] and associated that properly with my group membership
When using sssd, while the user would appear as first.last, group membership would never be applied. Here's what I mean.
dn: uid=first.last,cn=users,cn=compat,dc=ipa,dc=example,dc=com cn: First Last objectClass: posixAccount objectClass: top gidNumber: 1006800013 gecos: First Last uidNumber: 10000 loginShell: /bin/bash homeDirectory: /home/first.last uid:
[email protected] uid: first.last dn: cn=unixadm,cn=groups,cn=compat,dc=ipa,dc=example,dc=com gidNumber: 5900 objectClass: posixGroup objectClass: ipaOverrideTarget objectClass: ipaexternalgroup objectClass: top ipaAnchorUUID:: removed cn: unixadm memberUid:
[email protected]
I'm sure you see the problem. This causes other issues: If you're trying to use pam_hbac, it seems to want to work using pam_sss in the stack, not pam_ldap. With pam_ldap, it doesn't even try. With pam_sss, it tries, but it ultimately fails because it doesn't seem to be properly evaluating the rules and groups - again, this goes back to what I said: group membership is not seen with sssd fully while nss pam ldap can associate it to an extent.
As of this writing, I was never able to properly figure this out. What I noticed is in sssd, the group memberships were always intermittent. In fact, it always acted weird - if I did getent group unixadm, it'd show me. As soon as I ran id against my user, I'd disappear from the group. And I found this to be very troublesome. Sometimes it worked, other times it didn't. I could never really figure out why this was happening. One thing I did try was updating SSSD to 1.9.6 from a COPR repo. That didn't help.
Long story short: get rid of your RHEL 5 systems. At least RHEL 6 worked. Sort of.
Solaris 10
Alright, so this is where it gets interesting. Getting it to work with FreeIPA was a chore, a serious chore. The worst part about all of this is the communication from the system to FreeIPA is unencrypted. Yes, you heard this right. Unencrypted. I couldn't even get it to be OK with Kerberos login to at least have a secure channel. The saving grace here is that if you have a keytab on your system and login, it should just work. The other problem I had is I needed to use pam_ldap in my pam configuration.
First thing I needed is a profile that the ldapclient could use. I also created a solaris system account. Here's an example ldif below you can add into IPA.
dn: cn=solaris_authpam,ou=profile,dc=ipa,dc=example,dc=com serviceAuthenticationMethod: pam_ldap:simple authenticationMethod: simple objectClass: top objectClass: DUAConfigProfile bindTimeLimit: 5 cn: default cn: solaris_authpam defaultSearchBase: dc=ipa,dc=example,dc=com defaultServerList: pentl01.ipa.example.com pentl02.ipa.example.com followReferrals: TRUE objectclassMap: shadow:shadowAccount=posixAccount objectclassMap: passwd:posixAccount=posixaccount objectclassMap: group:posixGroup=posixgroup profileTTL: 6000 searchTimeLimit: 15 serviceSearchDescriptor: group:cn=groups,cn=compat,dc=ipa,dc=example,dc=com serviceSearchDescriptor: passwd:cn=users,cn=compat,dc=ipa,dc=example,dc=com serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=ipa,dc=example,dc=com serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=ipa,dc=example,dc=com serviceSearchDescriptor: sudoers:ou=sudoers,dc=ipa,dc=example,dc=com dn: uid=solaris,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject objectClass: top uid: solaris userPassword: secret123
I needed to create a keytab for the host.
# ipa host-add hostname.example.com # ipa-getkeytab -s pentl01.ipa.example.com -p host/
[email protected] -k /tmp/hostname.keytab
I then transferred the keytab to the system and put it at /etc/krb5/krb5.keytab. I configured /etc/krb5/krb5.conf.
[libdefaults] default_realm = IPA.EXAMPLE.COM dns_lookup_kdc = true verify_ap_req_nofail = false [realms] IPA.EXAMPLE.COM = { } DOMAIN.TLD = { } [domain_realm] ipa.example.com = IPA.EXAMPLE.COM .ipa.example.com = IPA.EXAMPLE.COM domain.tld = DOMAIN.TLD .domain.tld = DOMAIN.TLD [logging] default = FILE:/var/krb5/kdc.log kdc = FILE:/var/krb5/kdc.log kdc_rotate = { period = 1d version = 10 } [appdefaults] kinit = { renewable = true forwardable= true }
Set the permissions of the keytab to 600, owned by root:sys. Once it was configured, I tested kinit
[email protected]. If you get a message about "kt warn", it can be ignored. After this, set /etc/defaultdomain to your ipa domain (ipa.example.com). Configure /etc/ldap.conf.
base dc=ipa,dc=example,dc=com scope sub TLS_CACERTDIR /var/ldap TLS_CERT /var/ldap/cert8.db TLS_CACERT /var/ldap/ipa.pem tls_checkpeer no ssl off bind_timelimit 120 timelimit 120 uri ldap://pentl01.ipa.example.com sudoers_base ou=sudoers,dc=ipa,dc=example,dc=com pam_lookup_policy yes
Create /var/ldap if needed and create an NSS certificate database. You should also have your CA certificate as /var/ldap/ipa.pem.
# cd /var/ldap # /usr/sfw/bin/certutil -A -n "ca-cert" -i /var/ldap/ipa.pem -a -t CT -d .
At this point, I do the ldapclient init.
# ldapclient init -a profileName=solaris_authpam \ -a domainName=ipa.example.com \ -a proxyDN="uid=solaris,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com" \ -a proxyPassword="secret123" \ -D uid=solaris,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com \ -w qdbKnW1et pentl01.ipa.example.com
Now configure /etc/nsswitch.conf.
passwd: files ldap [NOTFOUND=return] group: files ldap [NOTFOUND=return] sudoers: files ldap netgroup: ldap
Now configure /etc/pam.conf
# Console login auth requisite pam_authtok_get.so.1 login auth sufficient pam_krb5.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_dial_auth.so.1 login auth required pam_unix_auth.so.1 use_first_pass login auth required pam_ldap.so.1 rlogin auth sufficient pam_rhosts_auth.so.1 rlogin auth requisite pam_authtok_get.so.1 rlogin auth sufficient pam_krb5.so.1 rlogin auth required pam_dhkeys.so.1 rlogin auth required pam_unix_cred.so.1 rlogin auth required pam_unix_auth.so.1 rlogin auth required pam_ldap.so.1 # Needed for krb krlogin auth required pam_unix_cred.so.1 krlogin auth sufficient pam_krb5.so.1 # Remote Shell rsh auth sufficient pam_rhosts_auth.so.1 rsh auth required pam_unix_cred.so.1 rsh auth binding pam_unix_auth.so.1 server_policy rsh auth required pam_ldap.so.1 # Needed for krb krsh auth required pam_unix_cred.so.1 krsh auth required pam_krb5.so.1 # ? ppp auth requisite pam_authtok_get.so.1 ppp auth required pam_dhkeys.so.1 ppp auth required pam_dial_auth.so.1 ppp auth binding pam_unix_auth.so.1 server_policy ppp auth required pam_ldap.so.1 # Other, used by sshd and "others" as a fallback other auth requisite pam_authtok_get.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth binding pam_unix_auth.so.1 server_policy other auth required pam_ldap.so.1 other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account binding pam_unix_account.so.1 server_policy other account required pam_ldap.so.1 other session required pam_unix_session.so.1 other password required pam_dhkeys.so.1 other password requisite pam_authtok_get.so.1 other password requisite pam_authtok_check.so.1 other password required pam_authtok_store.so.1 server_policy # passwd and cron passwd auth binding pam_passwd_auth.so.1 server_policy passwd auth required pam_ldap.so.1 cron account required pam_unix_account.so.1 # SSH Pubkey - Needed for openldap and still probably needed for ipa # without this, ssh keys stopped working. sshd-pubkey account required pam_unix_account.so.1
I installed pkgutil from OpenCSW. Seriously, this will help you out tremendously.
# /opt/csw/bin/pkgutil -y -i sudo sudo_ldap # vi /etc/opt/csw/sudo.conf Plugin sudoers_policy sudoers-ldap.so Plugin sudoers_io sudoers-ldap.so # ln -s /etc/ldap.conf /etc/opt/csw/ldap.conf
After that, I went ahead and tested id, logins, etc.
The current problem is that id won't show group membership, yet if you run the groups command, it will. Just because it shows the groups, doesn't mean you can really work with the files that are group owned as such. This only changes if you login via
[email protected].
Solaris 11
Solaris 11 was a lot more forgiving. I was able to get SSL to work and the sudo that they provide to work also. Most of the things above can be used. I'll point out which ones you can pull from above.
Create another profile on the IPA server.
dn: cn=solaris_authssl,ou=profile,dc=ipa,dc=example,dc=com authenticationMethod: tls:simple objectClass: top objectClass: DUAConfigProfile bindTimeLimit: 5 cn: default cn: solaris_authssl defaultSearchBase: dc=ipa,dc=example,dc=com defaultServerList: pentl01.ipa.example.com pentl02.ipa.example.com followReferrals: TRUE objectclassMap: shadow:shadowAccount=posixAccount objectclassMap: passwd:posixAccount=posixaccount objectclassMap: group:posixGroup=posixgroup searchTimeLimit: 15 serviceSearchDescriptor: group:cn=groups,cn=compat,dc=ipa,dc=example,dc=com serviceSearchDescriptor: passwd:cn=users,cn=compat,dc=ipa,dc=example,dc=com serviceSearchDescriptor: netgroup:cn=ng,cn=compat,dc=ipa,dc=example,dc=com serviceSearchDescriptor: ethers:cn=computers,cn=accounts,dc=ipa,dc=example,dc=com serviceSearchDescriptor: sudoers:ou=sudoers,dc=ipa,dc=example,dc=com profileTTL: 6000
Generate your keytabs and move them to the server.
Configure the krb5.conf file as necessary.
Set /etc/defaultdomain to your IPA domain.
Place IPA cacert into /var/ldap/ipa.pem
Your /etc/ldap.conf will need to be a tad different on Solaris 11. You will need to remove the TLS_CERT line. Solaris 11 no longer uses NSS.
base dc=ipa,dc=example,dc=com scope sub TLS_CACERTDIR /var/ldap TLS_CACERT /var/ldap/ipa.pem tls_checkpeer no ssl off bind_timelimit 120 timelimit 120 uri ldap://pentl01.ipa.example.com sudoers_base ou=sudoers,dc=ipa,dc=example,dc=com pam_lookup_policy yes
To configure nsswitch, you have to run commands (thanks oracle).
/usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/default = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/sudoer = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/password = astring: "files ldap [NOTFOUND=return]"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/group = astring: "files ldap [NOTFOUND=return]"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/host = astring: "files dns"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/network = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/protocol = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/rpc = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/ether = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/netmask = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/bootparam = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/publickey = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/netgroup = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/automount = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/alias = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/printer = astring: "user files"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/service = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/project = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/auth_attr = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/prof_attr = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/tnrhtp = astring: "files ldap"' /usr/sbin/svccfg -s svc:/system/name-service/switch 'setprop config/tnrhdb = astring: "files ldap"' /usr/sbin/svcadm refresh svc:/system/name-service/switch ; /usr/sbin/svcadm restart svc:/system/name-service/switch ; /usr/sbin/svcadm restart ldap/client
Now you need to setup all of your pam files. Here are the ones I configured and it worked.
# /etc/pam.d/krlogin auth required pam_unix_cred.so.1 auth required pam_krb5.so.1 # /etc/pam.d/krsh auth required pam_unix_cred.so.1 auth required pam_krb5.so.1 # /etc/pam.d/login auth requisite pam_authtok_get.so.1 auth sufficient pam_krb5.so.1 auth required pam_dhkeys.so.1 auth required pam_unix_cred.so.1 auth required pam_dial_auth.so.1 auth required pam_unix_auth.so.1 server_policy auth required pam_ldap.so.1 # /etc/pam.d/other auth definitive pam_user_policy.so.1 auth requisite pam_authtok_get.so.1 auth sufficient pam_krb5.so.1 auth required pam_dhkeys.so.1 auth required pam_unix_cred.so.1 auth required pam_unix_auth.so.1 server_policy auth required pam_ldap.so.1 account requisite pam_roles.so.1 account definitive pam_user_policy.so.1 account required pam_unix_account.so.1 server_policy account required pam_krb5.so.1 account required pam_tsol_account.so.1 account required pam_ldap.so.1 session definitive pam_user_policy.so.1 session required pam_unix_session.so.1 password definitive pam_user_policy.so.1 password include pam_authtok_common password sufficient pam_krb5.so.1 password required pam_authtok_store.so.1 server_policy # /etc/pam.d/passwd auth binding pam_passwd_auth.so.1 server_policy auth required pam_ldap.so.1 account requisite pam_roles.so.1 account definitive pam_user_policy.so.1 account required pam_unix_account.so.1 # /etc/pam.d/ppp auth requisite pam_authtok_get.so.1 auth required pam_dhkeys.so.1 auth required pam_unix_cred.so.1 auth required pam_dial_auth.so.1 auth required pam_unix_auth.so.1 server_policy auth required pam_ldap.so.1 # /etc/pam.d/rlogin auth definitive pam_user_policy.so.1 auth sufficient pam_rhosts_auth.so.1 auth requisite pam_authtok_get.so.1 auth sufficient pam_krb5.so.1 auth required pam_dhkeys.so.1 auth required pam_unix_cred.so.1 auth required pam_unix_auth.so.1 auth required pam_ldap.so.1 # /etc/pam.d/rsh auth definitive pam_user_policy.so.1 auth sufficient pam_rhosts_auth.so.1 auth required pam_unix_cred.so.1 auth required pam_ldap.so.1 # /etc/pam.d/sshd-pubkey account required pam_unix_account.so.1
The only issue is if you are using domain resolution order, trying to login without the realm name for AD users will cause an assertion error. I asked Oracle to fix this because Solaris 10 was fine. I don't know when they'll fix it. As of this writing, they claim October 20, 2017.
The actual current problem is that id won't show group membership, yet if you run the groups command, it will. Just because it shows the groups, doesn't mean you can really work with the files that are group owned as such. This only changes if you login via
[email protected] or remove the domain resolution order entirely - this would cause you to have to login with username@domain.
HBAC
For legacy clients to authenticate AD users properly, you need an HBAC rule against the IPA servers that perform the task of talking to AD. I'd recommend creating an ipaservers group (if one doesn't exist already) of all of your IPA servers, and then creating the hbac rules.
# ipa hbacsvc-add system-auth # ipa hbacrule-add system-auth-legacy # ipa hbacrule-add-host --hostgroup=ipaservers # ipa hbacrule-mod --usercat=all system-auth-legacy
For legacy clients, you need the pam_hbac module. For RHEL 5, there is a copr repo that you can pull the RPM's for. For Solaris, you are required to compile them, which isn't fun, I understand. Below I'll show you how to compile the modules and how to utilize the module.
Solaris 10 ++++++++++
You need to install OpenCSW's pkgutil. I also brought the sources of pam_hbac from github over as a git clone in a tar file.
root# pkgutil -y -i libglib2_dev gmake openssl binutils gcc4g++ glib2 ar libnet root# cd /tmp root# tar xf pam_hbac.tar root# cd /tmp/pam_hbac root# PATH=$PATH:/opt/csw/bin root# autoconf -o configure ; autoreconf -i root# ./configure AR=/opt/csw/bin/gar --with-pammoddir=/usr/lib/security --sysconfdir=/etc/ --disable-ssl root# vi Makefile.am ## Comment out the man pages #if HAVE_MANPAGES #SUBDIRS += doc #endif root# make root# make install root# /etc/pam_hbac.conf URI = ldap://pentl01.ipa.example.com BASE = dc=ipa,dc=example,dc=com BIND_DN = uid=hbac,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com BIND_PW = secret123 SSL_PATH = /var/ldap HOST_NAME = hostname.example.com
After this, you can place the hbac lines in your pam file. I usually put it under 'other' and 'login' as "account".
login auth requisite pam_authtok_get.so.1 login auth sufficient pam_krb5.so.1 login auth required pam_dhkeys.so.1 login auth required pam_unix_cred.so.1 login auth required pam_dial_auth.so.1 login auth required pam_unix_auth.so.1 use_first_pass login auth required pam_ldap.so.1 login account required pam_hbac.so ignore_unknown_user ignore_authinfo_unavail debug # other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account binding pam_unix_account.so.1 server_policy other account required pam_ldap.so.1 other account required pam_hbac.so ignore_unknown_user ignore_authinfo_unavail debug
To answer your question, yes. I had to disable SSL. This is because IPA has a lot of ciphers turned off. Solaris 10 doesn't support much higher, and because these are dynamically compiled (not static), they pick up both SSL libraries from OpenCSW and the system. But the system is picked up first and used.
Solaris 11 ++++++++++
Compiling on Solaris 11 is easier (thankfully).
root# pkg install autoconf libtool pkg-config automake gcc asciidoc docbook (some of these won't install, that's fine) root# cd /tmp root# tar xf pam_hbac.tar root# cd /tmp/pam_hbac root# autoreconf -if root# ./configure --with-pammoddir=/usr/lib/security --mandir=/usr/share/man --sysconfdir=/etc/ root# make root# make install root# /etc/pam_hbac.conf URI = ldap://pentl01.ipa.example.com BASE = dc=ipa,dc=example,dc=com BIND_DN = uid=hbac,cn=sysaccounts,cn=etc,dc=ipa,dc=example,dc=com BIND_PW = secret123 SSL_PATH = /var/ldap HOST_NAME = hostname.example.com
Pam is a little different here. I configured login and other just like on Solaris 10.
# goes at the VERY end of the account block in /etc/pam.d/other and /etc/pam.d/login account required pam_hbac.so ignore_unknown_user ignore_authinfo_unavail debug
General +++++++
You also need to create an hbac service in IPA.
# ipa hbacsvc-add sshd-gssapi # ipa hbacsvc-add sshd-kbdint
You would need to associate those in particular to your HBAC rule sets as needed for your legacy hosts.
Summary
What I've learned overall is that trying to get legacy clients to work with FreeIPA is actually simple if you were only using IPA. It begins to get tricky when you add in AD. The other thing I've learned is that there are companies that will not let go of their dying systems and we just have to live with it. Because this is the case and I know it will not change any time soon, I had to really put a lot of (unnecessary) effort into making this all work. RHEL 6 and RHEL 7? Easy. RHEL 5, Solaris 10/11? Not so easy.
This also gave me a more of a sour taste in my mouth about the political landscape of an enterprise. It's just flat out unfortunate. But, I am glad I got this experience so I can show others what I had to deal with and hopefully others can conquer it in the same way or even better than I have.
1 note
·
View note