I need to integrate a couple of AIX servers into an existing LDAP directory for user authentication and authorization. Versions range from 5 to 7.1.
On some systems (I have yet failed to recognize a pattern) I need to finish the '/etc/passwd' with a line containing a single '+' character for commands line id, login and automount to work. This procedure I took from the IBM Redbook "Integrating AIX into Heterogenous LDAP Environments", p. 125.
I'd be prepared to just accept that. However, I have systems which are integrated perfectly fine into the LDAP without that line in '/etc/passwd', i.e., which just work. I would like to understand exactly what that '+' does and what other files exist to configure the system to use LDAP for authentication and authorization. I have yet failed to graps the difference between systems which require '+' and those that do not.
Frankly, I am kind of afraid to mess with a facility like '/etc/passwd' without understanding what that '+' does exactly and what other options I have to enable LDAP lookup (apparently, others need to exist.)
Grateful for any help, cheers, Christopher
Related
Recently had an issue in an environment where we use ldap to update our system with groups / users. The LDAP system is not in our control, we can only run queries against it, and done within our code. The LDAP is part of the orgs single-sign on. The UI for this was upgraded and LDAP apparently untouched. Our system has a ldap member criteria that was set to "user, posixAccount" and "hard-coded", so not easy to change. Things stopped working and eventually identified that if we changed the case to posixaccount, things returned back to normal.
It's an absolute mystery how something that has worked for years suddenly stops working because from our side it was expecting posixAccount and not posixaccount, and we're told the upgrade didn't touch LDAP side of things.
Any ideas of what could've changed to have this effect?
(We are unable to get any info on the LDAP system or what was actually done. We can use ldapsearch for example which actually doesn't worry about the case and understand that it should be case insensitive, but that's secondary for now).
I just had an issue connecting to databases in my SQL Developer with the error
'unsupported verifier type'
I did some research on Google since our DBA team could not assist with this error. The suggestion based on my search was to add the line
AddVMOption -Doracle.jdbc.thinLogonCapability=o3
to the sqldeveloper.conf file.
Can somebody explain the importance of adding this line? What exactly does this line do?
Thank you.
This is a bug in Oracle side where certain applications especially running on WebSphere 7 with JDK 1.6 and ojdbc6.jar are not able to login to the Database. This is because of an Oracle driver “issue” when dealing with external 3rd party JCE libraries such as BouncyCastle.
Ref: https://vinaynotes.wordpress.com/tag/thinlogoncapability/
StackOverFlow Ref: ORA-01017 when connecting through jdbc thin driver
We found this parameter setting was necessary when authenticating to accounts that were using LDAP/Active Directory authentication ... IE enterprise user accounts (EUS) oracle accounts. Without this setting attempted logons received invalid id/password errors.
Good day.
I am developing a program that will be used in a corporate environment by the end users. The application will automatically fix certain errors as soon as the user selects the application name, chooses the symptom or error message and clicking on the fix button.
The idea behind is to decrease the amount of calls we receive at the IT Service Desk (The company's personal Call Centre for IT Issues) and at the same time assist the end user by resolving the issue within a minute (versus waiting on the phone for up to 15 minutes or more).
I've am not yet allowed to upload an image of the application, but imagine a small'ish windows form with 2 columns; Aplication name and Synptom. The user will choose the application's name, click on the error message and click on the FIX button. This basically automates whatever we has IT Techs would manually.
The problem I'm facing is that some of the code is supposed to be executed with adminsitartor rights, eg. Stop and Start a given service, adding regsitry entries for Local Machine, etc.
Given the fact that none of the users will be allowed to have elevated rights and the fact that they need to use this application as a sort of "self-help" alternative without the need to call the IT Service Desk, is there a way to give a set of code "administrator permissions"? The application should NOT request the user to enter ANY passwords.
Regards,
Willem
No way, AFAIK: the model in common operating systems is process-centric, so that the process is given permissions that are then inherited by its code. You can elevate such privileges at some point, but that will be for the whole future life of the process (or as long as the authentication token for it ceases to be valid).
In windows the right way to do that is to employ a back-end service: at boot, you start the service called IT_Auto_Fixer_Back_End with high permissions (try to avoid Administrator, NetworkService or LocalService could be enough for you). When the app IT_Auto_Fixer_Front_End is started with USER privileges, it operates until it needs something with high privileges. At that point it sends a request to the service, that will do it.
If you choose this way, some important advices:
The IT_Auto_Fixer_Back_End must not become a backdoor! If you use TCP as form of communication with IT_Auto_Fixer_Front_End, make it listen localhost only and use SSL (yes!) to encrypt local traffic
It must not be possible to invoke arbitrary commands using IT_Auto_Fixer_Back_End. You need to enumerate the possible requests that could be made (i.e. a command like stop_mysql_service rather than accepting directly the string net stop mysql - the application logic will translate your string into the real OS command)
Every input from the user could be used to perform command injection. To prevent this, use the Windows API that requires an array for the command - this way if the user adds options to a command (i.e. the name of the service in net stop) they won't be interpreted as another command (common scenario: when accepting the name of the service as a parameter, a malicious user that tries to execute something like net start mysql ; net user /add hacker t00E4sy). Authentication and encryption will not help you against this, you must escape any user input that goes inside the command.
Sanitize your ENVIRONMENT by using the API that executes commands setting the PATH (and other relevant variables), so that the user will not be able to taint the PATH, executing C:\temp\net.exe instead of C:\Windows\System32\Net.exe
IT_Auto_Fixer_Back_End service should be authenticated: it should check every time if the request comes form the user by checking if the Kerberos token is valid (Windows => you get a very nice Kerberos environment for free!). This will prevent someone else to break into the machine, use SSL to connect to the localhost port and elevate privileges through your service
The above (authentication) still stands when something else (i.e. shared memory, windows sockets, a file, etc...) is used as communication channel between IT_Auto_Fixer_Back_End and IT_Auto_Fixer_Front_End
Life gets harder when you want to properly implement something dealing with multiple level of permissions...
Am trying to configure Single sign-on using FreeRadius.
Scenario:
I have a fully configured LDAP (389 DS) Version-2.1 with few users and groups (in CentOS6).
I have installed FreeRadius (latest stable version) (in CentOS 6).
Configured FreeRadius to listen the above LDAP server.
I have made a client system (CentOS6) as radius client using pam_radius module. Now, am able to login to NAS with the LDAP credentials and getting logs correctly in FreeRadius.
Now, I want to implement single sign-on in this setup since I want to added some other devices like Firewall(Sonicwall) to authenticate.
I couldn't find any good docs to configure this.
Can someone please suggest me how to configure Single sign-on in the above setup?
For firewalls most people just use the accounting data to start and stop sessions as appropriate. This is usually triggering a script from within the accounting {} section of the freeradius server, creating the session on Acct-Status-Type == Start and destroying it on Acct-Status-Type == Stop.
If the PAM module sends Interim-Updates, you can record those in a database, and also set a 'lastupdated' timestamp. You then have a cronjob to check for rows where NOW() - lastupdated > (interim-interval * 2), and for those rows, delete the session on the firewall and close out the session in the database.
There is no proper SSO mechanism I know of which runs purely over RADIUS, the Project Moonshot guys were trying to get something working with SAML and a special EAP method, but it's probably too complex for what you want here, and not supported by PAM anyway.
I have been looking for information or examples of how to setup an IDM driver for Apple Open Directory. The articles I have found don't give much detail and pretty much no actual technical content.
I am using the LDAP driver and can connect and create a user on the OD side. However, the issue I am running into is how to set and synchronize passwords. Since it appears that the LDAP driver is not able to set the encrypted password correctly I was going to use dscl to set the password after the user is created by the driver. Since this step must occur after the XDS is submitted on the subscriber channel, can I create a follow-up event to trigger the dscl command or can I use the status message that comes back on the publisher channel?
It seems like synchronizing eDir to Apple Open Directory with IDM should not be something new. I am a little surprised that there is not an existing driver configuration in the Designer palette or at least some more detailed examples or discussions in the forums.
The answer I worked out was to write custom Java classes to make command line calls to the ODM server to set the password and also to do some group updates. 90% of the work is done using the standard LDAP driver.