I'm working with a fileserver that was connected to an old domain a few years ago. For some reason, the old domain is now gone and replaced by a new one. The only problem is that there are still some NTFS Permissions that uses the old users, of the old domain (OLDDOMAIN\User).
I Want to replace these permissions with the users on the new domein (NEWDOMAIN\User). Every user on the old domain has the same user on the new domain.
Is there a way to do this with powershell, or maybe an other way? I've already tried 'NTFSSecurity (https://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85), but I'm not sure if this is the best way to do it.
I guess this question rather belongs to Server Fault, but I'd use ADMT (Active Directory Migration Tool, https://technet.microsoft.com/en-us/library/cc974332%28v=ws.10%29.aspx).
Related
This question has been asked before and I've spent two days chewing through it all, to no avail. I've worked in and around DNN since the very early days (anyone remember the IBuySpy portal from 20 years ago?), and I've migrated more than a dozen sites, all without issue. But in this case, I'm getting the old "object reference not set to..." The EventLog indicates an error in InitializePage but not much more to go on. The logs in the DNN _default folder are for some reason not populating; will check this.
The specifics: DNN 5.03.01 site, has worked fine for a client for years. Needs to be moved to a new server. Different domain name for testing, then we'll redirect the live domain name. Site has a default portal at Portals/0 (no longer used); client's portal is at Portals/1. DB is on same box, MS SQL Server.
What I did: created a Portal Alias in the old, live site to reflect the "test" domain name. Copied all file system content. Duped schema to new DB (same version of MS SQL Server), used Schema Compare to make sure it worked, added all data, used Data Compare to make sure it was all there. Logged into new DB using SMSS; works fine. On the new/test DB, disabled all entries in the WebServers table. Verified new portal alias exists, referencing Portals/1. Verified domain name is live with correct new IP. Set up new site on IIS using that IP, referencing Portals/1. Edited connectionstrings and appsettings entries in Web.config, using the credentials that worked with SMSS. Ran the new site by entering the new/test domain name. I also set the permissions broadly on the DNN folder.
Got: [new domain name]/Default.aspx?error=Object+reference+not+set+to+an+instance+of+an+object.&content=0
So I'm getting to the DNN folder on the new server, but it seems something's not right with PortalSettings (guessing here). Maybe it's going to Portal 0 (the defunct one). This shouldn't happen if I create the new PortalAlias before migrating.
Possible complicating factor: The new server contains another complete instance of DNN which handles the live version (a copy) of the Portals/0 portal on the old machine.
Anybody have any thoughts? Something I overlooked? How can I make absolutely certain I'm hitting the database?
In the older versions of DNN there was a PortalSetting value for DefaultPortalAlias. If that was set to something different it is possible you could see similar behavior.
Also, that version of DNN does not log entries to the /portals/_default/logs directory
This question already has an answer here:
Forgot the username and password of *fdb (firebird) database. Is there anyway I can crack this database?
(1 answer)
Closed 4 years ago.
I got a computer which has already installed Firebird database 2.0. And now I need to open fdb files which are Firebird database files just on this computer. So what I need is to get the password of Firebird server.
I've tried the default user and password :SYSDBA and masterkey and it doesn't work.
I've also tried to copy the fdb files to another computer on which I installed the same version Firebird. Those files can be opened on that computer, but what I need is to get the username and password and connect to database on this machine rather than open on another computer.
Error: Your user name and password are not defined.Ask your database
administrator to set up a Firebird login.
I will assume you computers run under Microsoft Windows.
Things are a bit different in UNIX w.r.t. location of security database and details of using Embedded edition of FB.
However before the question got edited Windows was specified: https://stackoverflow.com/revisions/53881670/1
I've tried the default user and password :SYSDBA and masterkey and it doesn't work.
In which program?
If there is some 3rd-party application its login/password pairs might well be different from ones of the Firebird server itself.
security2.fdb in the Firebird 2.x installation folder contains users and password hashes.
So, depending upon what you actually need, you have two ways:
Remove all passwords, except for SYSDBA/masterkey. That is: remove the Firebird. Ensure that "security database" was removed too (if not - rename it or move to another folder). Reinstall Firebird afresh. Would let you peep into the database using development tools (IBExpert/FlameRobin/FirebirdMaestro and so forth) but would probably screw any 3rd-party applications that used that database (as that application's users would be no more existing in the FB server).
Clone users/passwords from old computer to new one. That is, after installing matching Firebird versions on both computer you would have to STOP the FB service on both computer, then copy the "security database" from old to new computer, then START the FB service on both computers.
This would probably make the 3rd party application work, but not let you use SYSDBA/masterkey with development tools.
In both cases you would also have to look into UDF sub-folder in Firebird installations - if there are some non-standard plugin DLLs there you might need to copy them to the new Firebird installation too, as some parts of the database might be dependent upon those (or not, but you do not know before you open the database).
Actually, there might be yet another route for a short-term peeping into the database. Download and unpack Firebird 2 Embedded edition. STOP (temporarily or even forever) the normal Firebird service on that computer (so the database file would no more be locked). Use the embedded Firebird (fbEmbed.dll) as the "client library" in one of the aforementioned developer tools. With Embedded server editions user password just does not matter.
Sorry about my english level.
I researched so much, and i found that can i use ".htaccess" to get redirection to subdomain folder and this is OK.
In Drupal i need to create a folder for each subdomain in "/sites/sub.example.com/" and copy "default.settings.php" from default folder "/sites/default/default.setting.php" and rename it to "settings.php", after that, enable "$databases" variable in the same file, when it's done, i need to add a wildcard and modify "hosts" file.
Well, i should "automate" all this, but i don't know if it's is more hard because it's important hold the server safety with writing permissions or try another way, someone could advise me.
Im working on OSX and Drupal 7.x (recent release)
Thank you very much.
For each site that you want to use separate database, create own sites/ directory with settings.php. For example, if you want to have one database for example.com, another one for sub1.example.com and third one for sub2.example.com, all using same code base, setup your files like this:
sites/example.com/settings.php
sites/sub1.example.com/settings.php
sites/sub2.example.com/settings.php
each settings.php using different database credentials.
Read more here - https://drupal.org/documentation/install/multi-site
Also, if you want to automate this and if there is supposed to be bigger number of sites to be managed, consider deploying aegir - http://www.aegirproject.org.
I hope I understood your question correctly.
The title doesn't really sum it all up...
I have recently installed ModX Revolution 2.2.4 on an Apache server and I am having complications with the cache folder. Occasionally I have to manually clear the cache folder via ftp, but any files written there are owned by Apache and my account can't delete them. I have tried adding the "new_file_permissions" and "new_folder_permissions" to the system settings, but there is no change. The cache files are always owned by Apache and I have no access via ftp.
Also, files such as the .htaccess and really anything I upload (css etc) are seen as uneditable to modx unless I manually change them to 777 via ftp. I can't change owner and group though.
The server tech can't figure it out. This has come up before on the modx forums but it has never been answered.
Obviously, this is a server problem.
I had this problem (with an IIS server though), and the host needed to change some of their settings.
Especially, if MODX works on your different host(s).
That is the way it is supposed to work, your FTP account does not have permission to write files written by apache, your ftp may be a member of the group but does not have write permission. [needed to delete]. I suspect this is by design for security purposes.
Your new_file_permissions, new_folder_permissions are used for the modx file manager.
So you can do a couple of things:
Run modx under fastcgi, that way the user writing the files should be the same user as the ftp user.
OR
write a little script [you can even stuff it in a snippet] that will delete the cache files for you. [since it will be running as the apache user, it should be no problem.
Obviously I am very new, so please bear with me.
I installed Kohana Framework in my localhost. To do is so we have to set two specific folders with write permissions to all. "chmod 666" is suggested. (here)
The remaining directories are set to 755.
My question is more directed to Apache.
Will the use of "chmod 666" create a vulnerability in a webserver?
What exacly means "write access for everyone"?
Many thanks in advance!
666 is almost always a really bad idea. The web site where you read that needs a good flogging.
"Write access for everyone" means that anyone with a user account on your system can write to that directory.
These rights are only for your current server, so if you are the only one with access to a user account on your machine you should be pretty safe. Write access for everyone means everyone with a user account on your machine has the right to write. Please note that 3rd party software (like apache) can have it's own user as well and this could be compromised if there's a exploit in that software. This way someone from the outside could gain access to that folder. It's a common practice to only give rights to users that really need access.
Note: On a normal Windows machine (don't know if this is still true with Windows 7 though) everyone has access to everyone's files. So this is just another security measure.