Laserfiche User Authentication Options

You ever feel like you need a secret decoder ring just to log into all the different software you use? I know I do sometimes. Oh, definitely. Especially with something as well as powerful and integrated as laser fech. So, let's unpack this. Good idea. We're taking a deep dive today into the various ways you can prove it's really you trying to access laser fish. We've got a great article here from CDI that lays this all out. Exactly. And our goal really is to simplify what can seem like a pretty complex topic, user authentication in Laser Fish. Yeah, that CDI article is uh yeah, it's a fantastic resource. We're here to pull out the crucial bits for you. Okay. And the article, it highlights three main ways Laserfish verifies who you are. You've got the standard Laser Fish user account, you know, with a password, right? The classic way. Then leveraging your existing Windows network credentials. That's Windows authentication. And then this third one, LDIP authentication. Now, the article makes a really interesting point right off the bat about that last one, LDIP. Yeah. What's fascinating there, and the article points this out, is how little traction LDIP seems to have gained in, let's say, typical environments, you know, outside of very specific network setups. Why is that, though? Well, the underlying technology, the protocols it uses, they just haven't become like super widely adopted across the board. So for the vast majority of you listening, the real focus is going to be on those first two. Laserfish user accounts and Windows authentication, especially if your organization relies on Microsoft Active Directory, right? Absolutely. If you're using Microsoft AD, as the article notes, Windows authentication is often well usually the preferred method. We can definitely dig into why that is. Okay. But before we get into the, you know, the nitty-gritty of each one, maybe a little background helps. The CDI article touches on this. a time before laserfish directory server LFDS. Ah yes, LFDS or as some might remember it license manager, right? License manager. Yeah. If we connect this to the bigger picture, um before LFDS really came along and matured, managing who had access to Laser Fish was often done well repository by repository. Oh wow. Yeah. You might have had totally separate user accounts for each different laser fee repository someone needed to use. It could get uh pretty messy honestly. I could imagine. So you could create a laser fee specific user just for one repository. Exactly. Or you could link a Windows account to access only that single repository. And even when laser fish forms first came out, it initially authenticated against a specific repository's user list too. But as laserfish grew, you know, more products, different licenses, it became clear that a central way to handle identities across all these pieces was needed. And that's where LFDS stepped in. Okay, so it sounds like it used to be a bit of a wild west with user management. You could say that LFDS was definitely a gamecher for streamlining things. So this raises a key question then how do these different ways of authenticating actually work today especially now that LFDS is often in the picture? That's the core of it. Our mission for you the listener is to really get the differences between these methods laserfish user versus Windows off and what that means for your security and just well managing your laser fish environment dayto-day. Okay, let's start with the maybe the most basic one. The laser fish user authentication. The CDI article explains you've got a couple of options here. Mhm. You can create these users directly within the laser feature administration console. Maybe if you're just dealing with a single repository, correct? Simple setup. Or you can create them in LFDS for broader access. So let's say you are using LFDS. How do you actually go about setting up a laser fee user there? Okay, so the article walks us through it. In LFDS itself, you go to the accounts tab. Pretty straightforward, right? Then choose to add a new user. One of the choices you'll see right there is laserfish user. Makes sense. You pick that and then you need to set a username, obviously a password, and crucially the appropriate license type for that user. And what's really interesting here, as the article points out, is that doing this in LFDS creates what you'd call a global laser fish user. a global user. Yeah. Meaning their identity is recognized across different parts of your laser fus setup. Yeah. Yeah. Not just one repository. Exactly. It's known by the central LFDs system. So if you've created this global laserfish user in LFDS, how do you then um grant them access to a specific repository? Because creating them isn't enough, is it? No, absolutely not. That's a key step. There are a couple of ways depending on the tool you're using. If you're using the classic laserfish Windows administration console, the thick client, yeah, right, you would add what's called a laserfish directory account. Now, think of this laserfish directory account as like the link or the placeholder for that global LFDS user within that specific repository. Oh, okay. Like an alias or pointer kind of. Yeah. When you add one, you can then search LFDs for the specific username you created globally. And in the newer web management console, similar idea. You'd add a user, choose the type laserfish, and then there's usually a search icon to find that LFDS user account. The CDI article also mentions the trust authentication setting in the Windows admin console. Specifically in this context, trust. What does that signify? By setting the authentication to trust, you're essentially telling that repository, hey, I trust that LFDs has already verified who this person is. Just let them in based on the LFDS login. Gotcha. Okay. Now, what if you're not using LFDS or maybe you have a specific reason to create a laser fish user that's only relevant to one single repository? How does that work? The article covers that scenario, too. So, if you're not using LFDS or choose not to for a specific user, you can still create a Laserfish user directly within a repository settings. Oh, in the Windows admin console, you'd navigate under users and groups and then rightclick on repository users to create a new one. Okay. In the web management console, you'd again hit that add user icon, but this time you'd explicitly choose to add a repository user type. Ah, so you specify it's just for this repository. Precisely. And here's where it's different. When you create this nonLFDS repository only laserfish user, you are setting the username, the password, and the license type right there specifically for that repository. It doesn't exist anywhere else. Okay, that makes sense. direct control for that one place. And importantly, the article really highlights this. You absolutely must set a password for these repository specific users or at the very least check the box that says user must change password at next signin. Seems obvious, but why the emphasis? Well, it might seem obvious, but you'd be surprised. It's a basic security step. If you create the user but forget the password or that checkbox, you've essentially created an account that can't be logged into or worse has a known default or blank password, it's like leaving the key under the mat as the article implies. This ensures at least that basic level of security. Good point. Okay, so that's the laser feed user side global via LFDS or local to a repository. Now, let's switch gears. Windows authentication. The CDI article states pretty clearly if your organization uses Microsoft Active Directory then laserfish Windows users are generally preferred. Why is that? Right. The key advantage and it's a big one is that you're leveraging the user accounts and importantly the security policies that are already set up and managed within your Windows Active Directory environment. So no separate Laserfish password to manage. Exactly. that inherently enhances security because you're not creating and managing a whole separate set of credentials maybe with weaker policies. Think about password fatigue. Oh yeah, users have so many login. Windows authentication helps because they use their familiar hopefully strong Windows password managed by your AD policy and easier for it too. I imagine definitely simplifies administration. User leaves the company disable their AD account and their laser fee access tied to it is typically gone too. You're managing users in one place active directory. It follows that principle of lease privilege nicely to extending existing accounts rather than creating new silos. That makes a lot of sense. Okay. So, how do you actually add a Windows user to laserfish when you are using LFDS? Is it similar to adding a laser fish user? It is quite similar following the CDI article again. In LFDS, you navigate back to that accounts tab, choose to add a user, but this time you select the Windows Active Directory user option. Okay. You'll then get a search function. This lets you look for specific users or even entire security groups within your actual Active Directory domain. So, you can add a whole group at once. Yes. Which is very efficient. You find the user or group you want, add them to the list of users being registered in LFDs, and click okay. Great. Now, the article has a really important note right after explaining this. a crucial distinction it seems. It says that just registering a user in LFDS doesn't automatically give them access to a laserfish repository. Can you unpack that a bit? Yes, this is super important and a common point of confusion. Think of LFDS as the central gatekeeper or directory. It knows about your users, both the laserfish ones we talked about and these Windows-based ones. It confirms they exist in your system. Okay. However, you still need to explicitly grant those users, even the Windows AD users registered in LFDS access rights within each specific laserfish repository they need to use. You do that using the repositories admin console, either the Windows one or the web one. So, LFDS registration is step one. Repository access is step two. Exactly. We often see folks do step one and then wonder why users can't log in. You need both steps. Got it. LFTS knows who they are. The repository knows what they can do there. Now, what if you want to add a Windows user directly to a single repository? Maybe bypass LFDS for some reason, or maybe they aren't registered there yet. Is that possible? It is. The CDI article outlines this, too. Whether they've been added to LFDS first or not, you can add a Windows user directly into a single repositories configuration. How's that done? In the Laserfish Windows admin console, you'd find the Windows accounts node under users and groups. Rightclick and add there. Okay. or in the web management console, you use that familiar add user icon again, but this time choose the Windows type and then use the search icon to find the specific Windows Active Directory account or group. But why might you do that directly instead of through LFDS if you're already managing users in AD? That's a fair question. For most organizations already using Active Directory and maybe multiple laser fech parts, going through LFDS first usually makes the most sense for that centralized view. But perhaps in a really small setup or maybe for very temporary access or if LFGs isn't part of your configuration, adding directly to the repository might seem like a quicker, more isolated approach for that one instance. Generally though, LFDS adds value. Okay. And when you add them directly like this or even after linking an LFDS Windows user, you're setting their permissions within that repository, right? Things like license type again and feature rights. Correct. You define what they can actually do in that repository. view documents, edit metadata, run workflows, etc. That's all done via feature rights. The article also mentions assigned privileges. Yeah, it says end users typically don't need those. That's right. Assigned privileges are more powerful administrative rights within the repository itself, like managing users, changing settings. Your typical end user just needs the feature rights relevant to their job. Got it. So recapping the Windows side, you leverage existing AD accounts, ideally register them in LFDs for central management, but always need to grant specific access and rights within each repository they need to use. You got it. And this brings us back nicely to the key advantages of using LFDS in the first place which the CDI article summarizes well which is primarily primarily that centralized user authentication across multiple laser fuch repositories and even other connected applications like laserfish forms. It really becomes that single point of management for all your laserfish users regardless of how they authenticate. One place to see who has access to what potentially pretty much it simplifies things immensely especially as your laser fish usage grows. The article also gives a brief nod to a couple of other LFDS capabilities, though says they're outside the scope of this discussion. One was synchronizing with Active Directory. Yeah, LFDS can be set up to monitor specific AD groups. When a new user gets added to that group in Active Directory, LFDS can automatically register them. It's a neat automation feature. And the other was single sign on SSO using SAML, right? LFDS also supports SAML authentication which allows for true single sign on. Log in once to your corporate network or identity provider and get access to laserfish and other SL enabled apps without logging in again. Big convenience and security booster. But yeah, a whole topic in itself. Okay, both sound like powerful extensions building on that central LFDs foundation. Now, just to circle back quickly to the third method mentioned right at the start, LEP, the article basically said it's rare. Can you just reiterate why? Sure. As the CDI article explains, LDAP, which stands for lightweight directory access protocol, is designed to work with directory systems following a standard called X.50. Okay. The simple reason we don't see it much in typical laser fee setups is that those specific underlying LDF protocols just haven't seen widespread adoption across the general IT industry compared to say Active Directory. So you're really unlikely to bump into needing LDA unless you're in a very specific often older network environment that heavily relies on it. Fair enough. So for probably 99% of the people listening, the real decision comes down to Laserfish user accounts versus Windows Active Directory accounts. That's a core choice. Yeah. Within Laserfish user accounts, the decision is whether to manage them globally via LFDS or keep them specific to individual repositories. Exactly. Windows authentication generally offers those big wins on security and admin ease if you have active directory and LFDs provides that crucial layer of centralized management especially when you have multiple laser fe pieces repositories forms etc. Okay so that really clarifies the landscape. It's about understanding these options and how they fit or don't fit with your existing infrastructure and needs precisely. It's not always a one-sizefits-all answer. All right. So here's the final thought then for you listening to chew on considering your own organization setup your infrastructure your security requirements how many laser fish parts you use which of these authentication methods laser fish user or Windows ad seems like the most efficient and secure approach for your laser fish environment and following from that what further questions might you have about actually implementing or managing these options day-to-day that's the critical takeaway question really thinking about your context and if you want to dive deeper that CDI article we've been referencing is a great resource. Plus, LaserFish's own official documentation is very thorough. Or, of course, you could reach out to experts like the folks at CDI for more tailored advice. [Music]